sorenbs

We are running Postgres and Bun on the same tech at Prisma. It’s good.

Indeed. Cost of nuclear is static or climbing. Renewables are cheaper and falling. Batteries are about the same, and falling.

If a western country starts building nuclear today, they will have something to show for it in ten years at the earliest. Renewables and batteries are already cheap, and getting cheaper, so it seems like a very silly bet. Especially in a place like Italy with excellent sun and lots of space.

It's a canary releasing directly from main: https://github.com/oven-sh/bun

We have run it in production for a month: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute

We found the Rust based canary version to solve a number of memory leaks that we were struggling with in the Zig based 1.3. One of our engineers wrote up the details here: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute

We worked with the CipherStash team to build a Prisma Next extension that provides full type safety for their additional query shapes, and a fully managed experience for applying schema changes. It was a great experience working with the team, and we were particularly excited about this, as it helped us prove out the new extensibility mechanisms we have been working so hard for in Prisma Next.

Docs here: https://cipherstash.com/docs/stack/cipherstash/encryption/pr...

And a mention in our April update on Prisma Next: https://www.prisma.io/blog/prisma-next-roadmap-april-milesto...

If you want to give CipherStash on Supabase a try, using Prisma Next is the smoothest experience.

There's a lot of new stuff here. The complete rewrite in TypeScript alone is a huge improvement. But the new migration system is probably the most ambitious part. Very curious for feedback on that!

Yeah. Completely changes the meaning of the article. I thought Nvidia was now competing with Cerebras. That's not the case...

If chip manufacturing advances allow them to eventually run leading edge models at speeds much faster than competition, that seems a really bright future all on its own. Their current chip is reportedly 5nm already, and much too small for the real 5.3-codex: https://www.cerebras.ai/press-release/cerebras-announces-thi...

We operate a postgres service on Firecracker. You can create as many databases as you want, and we memory-snapshot them after 5 seconds of inactivity, and spin them up again in 50ms when a query arrives.

https://www.prisma.io/postgres

> but some others will pick up where he left off, with more modest goals

Already happening :-) https://github.com/Dicklesworthstone/beads_rust

I've had a lot of fun playing this the past weeks. And very happy to learn the game uses Prisma on the backend :-)

I've had a really good time using https://github.com/lima-vm/lima

I am somehow uniquely well positioned to answer this question. I worked at Trustpilot for 7 years, and am now a relatively large Vultr customer.

Vultr is great!

Very interesting announcement!

We are also building a hosted Postgres service based on Firecracker and with the ability to create unlimited databases. Will have to dig in and see how we compare to this. https://www.prisma.io/blog/announcing-prisma-postgres-early-...

That would be billed as a single query. We think this is a much simpler way to reason about your cost compared to counting rows scanned, CPU time consumed or something more granular like that.

If your query is very expensive, it will take longer to complete, and that will be a signal to you the developer to simplify your query or identify an index that can help speed it up. Prisma Optimise will help you identify and improve such queries.

Thank you!

Reclaiming memory is orthogonal to unikernals. It's a concern of the VMM, and Firecracker does support this through the balloon device: https://github.com/firecracker-microvm/firecracker/blob/main...

Now, the unikernel helps us consume less memory, which is a good place to start :-)

We are looking for input on this during the EA phase. Here's how we plan for this to work:

- Each incremental concurrent query allocates additional compute resource to your database - All queries share that pool of compute resource - Queries have strict timeout limits. 10 seconds on most plans configurable up to 60 seconds.

Prisma Postgres is designed to serve interactive applications with users waiting for a response. In a sense, we are adopting some of the design principles underlying DynamoDB (strict limits on queries) and combining it with the flexibility of a Postgres database that is fully yours to configure and use as you see fit.

It's not every day you get to launch a hosted Postgres service that has something fundamentally new to offer. That's what we have done with Prisma Postgres, and I'm incredibly excited for it.

We are using Firecracker and unikernals to deliver true scale-to-zero without cold-starts. Happy to go into more detail if anyone is interested.

Existing discussion: https://news.ycombinator.com/item?id=41805515

We are using SQLx under the hood to generate types for SQLite in https://www.prisma.io/typedsql. It's really great.

I am super excited for this release. We build Prisma Optimize with inspiration from a tool I used as a young software developer almost 15 years ago, nhprof: https://hibernatingrhinos.com/products/nhprof

Technology has come a long way, and the addition of an AI agent that can help answer questions about your query patterns and the recommendations we provide has turned out to be super helpful.

If you are using Prisma, please give it a try and let us know if there is anything you think we could improve. We are already working on many more recommendations to help you catch different kinds of performance problems.

This is such a great approach.

Coincidentally, we just released support for this in Prisma a few weeks ago: https://www.prisma.io/blog/announcing-typedsql-make-your-raw...

This data is super interesting to us as we are operating a large network across AWS and Cloudflare.

Is there any specific data you would like us to include next time?

No. A DO only exists in a single edge location. That's the entire point of Durable Objects.

D1 will replicate soon, but doesn't do so yet. My understanding is that it will replicate to ~5 locations and keep these locations fresh.

This setup can work great and even support elements that are shared between users, if you also give those elements their own DB. I’m working on a prototype to support this natively in Prisma.

How are you handling the security boundary between tenants? Is each edge function run in a separate Deno process in a VM?

If anybody has problems with Prisma, please reach out to me on Twitter. DMs open: https://twitter.com/sorenbs

We changed the wire protocol in Prisma 4.11. You can read about the significant performance improvements here: https://www.prisma.io/blog/prisma-5-f66prwkjx72s

Prisma is going to significantly improve support for edge functions soon. We are compiling our Query Engine to WASM, and have already added support for Serverless APIs from PlanetScale and Neon.

You can fill out the survey here if you'd like early access to this: https://github.com/prisma/prisma/issues/21394

We'll make some noice about this together with Supabase when it is ready, so you won't miss it :-)

At Prisma, the "twelve easy steps" for performing a table change in SQLite documented on https://sqlite.org/lang_altertable.html is a bit of a running joke.

SQLite is super versatile, but very different from other more traditional RDMBS.