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.
Wow, I thought you guys were just reselling Neon like some others. This is genuinely impressive technically. It's got me looking at Unikraft Cloud for other stuff too.
That said, do you plan do offer branching or any other features that Neon offer? I think that's their big selling point along with separate billing for compute and storage.
Prisma team member here... Yes, when we go GA, we'll offer features that'll give you the comfort of wanting to run your production loads on Prisma Postgres!
Essentially, you pay for database queries and events, with 60'000 included for free, which is plenty for experimenting and small projects. Price per million queries/events is then based on the plan you're subscribed to, and with Starter you have zero monthly fixed costs and only pay for queries and events above 60'000.
No CPU-time and similar that's usually hard to grok.
Take a look at the Accelerate and Pulse pricing details. Prisma Postgres comes bundled with these, so the pay-as-you-go pricing is the same: https://www.prisma.io/pricing#accelerate
We'll continue to make improvements to the pricing on the way to General Availability to make it both as easy to understand and affordable as possible.
If pricing is only done by storage limits, egress and query count (but not resource usage) how do you prevent something like a massive cross join with an aggregation from just running for ages on a single query?
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.
Does that mean that using Prisma Accelerate and Pulse with an external database will cost the same as using it with the bundled database? (Since I don’t see database-specific costs for storage, read replicas, PITR, backups)
While Prisma Postgres in in early access, yes. This is why there's no ability to change the database config right now.
However, when we release Prisma Postgres in GA (couple of months), you will be able to upgrade your postgres instance (CPU, storage, etc.) and that will be db-specific cost.
Prisma was born out of graph.cool (https://www.graph.cool/) and their GraphQL implementation became the middleware between the Prisma DB client (@prisma/client) and their Rust db abstraction layer (prisma-engine).
I believe they're getting rid of the residual GraphQL bits though, if I'm not mistaken.
Nikolas from Prisma here! I've been around for almost 8 years (since the Graphcool days) and this description is pretty accurate but I can add a bit more color. The major product evolutions we've had were:
- Graphcool: A GraphQL BaaS written in Scala.
- Prisma 1 (see [1]): A GraphQL proxy server between DB and app server. This was essentially the "GraphQL engine" of Graphcool that we ripped out and made it available as an open-source component. However, its auto-generated CRUD GraphQL API never was meant to be consumed by a frontend. Instead, it was the abstraction layer for the app server to interact with the DB (at first only for GraphQL APIs on the app server via `prisma-binding`, then the first version of Prisma Client that worked with any API layer — both of these were thin JS/TS layers that talked to the GraphQL proxy server where the actual DB queries were generated).
- Prisma 2+ aka Prisma ORM (see [3]): We realized that with Prisma 1, we were essentially competing with ORMs but that our architecture was way too complex (devs needed to stand up and manage an entire server where other ORMs could be used with a simple `npm install`). So, we rewrote the Scala "DB-to-GraphQL" engine in Rust to be able to provision it via a download during `npm install` and run it as a sidecar process on the app server, added a migration system and Prisma ORM was born. That being said, it has evolved a lot since then. We dropped GraphQL in favor of a way more efficient wire protocol [4] and have continuously reduced the footprint and responsibility of the query engine (e.g. you can now use Prisma ORM with standard Node.js DB drivers [5]).
If you want more details, I talked more about this evolution on Twitter [6] a while ago.
This launch is a huge milestone for us and it's definitely one of the most exciting launches I've been a part of at Prisma!
> Essentially, you pay for database queries and events, with 60'000 included for free, which is plenty for experimenting and small projects. Price per million queries/events is then based on the plan you're subscribed to, and with Starter you have zero monthly fixed costs and only pay for queries and events above 60'000. No CPU-time and similar that's usually hard to grok.
Take a look at the Accelerate and Pulse pricing details. Prisma Postgres comes bundled with these, so the pay-as-you-go pricing is the same: https://www.prisma.io/pricing#accelerate
We'll continue to make improvements to the pricing on the way to General Availability to make it both as easy to understand and affordable as possible.
Nvm answered further down in the thread by eampiart
Our pricing for Prisma Postgres indeed presents a bit of a mental shift compared to traditional database providers:
We charge for query volume, not for compute!
We believe that ultimately this is a more intuitive way for developers to think about database cost.
Generally, our goal is that developers need to only think about _queries_ — we'll take care of everything else to make sure those queries can run efficiently. Developers shouldn't need to worry about compute, scaling, downtime, etc.
How about the scenario where I do a select … where … on a view and that view is defined to have 5 CTEs on different tables and then a final select doing some complex stuff there.
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.
While I think as an arm-chair business wonk y’all should count it as 6 queries and not 1 as a payer and consumer I’m even more likely to use it now that you count us as only a single query. :-)
I just answered the same questions on Twitter [1], so just quoting that:
Neon is a lot more feature-rich right now (since PPG just came out) and has awesome stuff like branching.
On the long-run, we expect to have a similar feature set. Additionally, our underlying tech has the benefits of avoiding cold starts and likely being more cost-effective.
That being said, I see it as a major benefit that with Prisma you not only get a DB but an entire data layer (incl global caching and real-time DB events) thanks to the first-class integration of our other products like Accelerate and Pulse [2].
Congrats on the launch, this looks very interesting!
Will it ever be possible to self-host Prisma Postgres (or Pulse)? It's great that I can use your platform, but if I adopted e.g. Pulse, that's a non-trivial vendor lock in. I'd feel _much_ safer/confident building my app around the Prisma stack (besides the ORM, which I like).
Self-hosting for Prisma Postgres, Pulse, and Accelerate isn’t currently on the agenda. Our focus is on building Prisma into a company that gives developers the best tools for working with data. We handle a lot of the underlying complexity, abstracting it away to make the developer experience seamless so that teams can concentrate on building their applications rather than worrying about infrastructure—just as we do with databases and the Prisma ORM.
Your point about concerns around vendor lock-in is completely valid, and we get it. However, we're confident that our approach with the ORM, along with the trust we’ve built with the community, will set the stage for us to develop long-term commercial products that are fit for serious, production-ready deployments.
Just to give you a bit more context, I've been evaluating CDC (change data capture) tooling and Prisma Pulse was one of the options. My primary data storage is Postgres but I have a need to react when data in some tables is changed (depending on some user-provided filters). I'm currently handling that with naive message push to SQS, because Debezium/Kafka setup is too expensive/complex. Prisma Pulse looks great, but that CDC part of my app is crucial and I need an option to be able to host it myself/on premises for some customers.
However I totally understand the need to build a moat — good luck on your journey!
wow cool. Never heard about unikernels. Does it solve the issue with firecracker of not being able to reclaim memory? Would imagine that can be an issue for a long running app like a constantly busy database
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.
Wow, I thought you guys were just reselling Neon like some others. This is genuinely impressive technically. It's got me looking at Unikraft Cloud for other stuff too.
That said, do you plan do offer branching or any other features that Neon offer? I think that's their big selling point along with separate billing for compute and storage.
Prisma team member here... Yes, when we go GA, we'll offer features that'll give you the comfort of wanting to run your production loads on Prisma Postgres!
Congrats on the launch!
I’m a bit confused about the pricing.
The docs and pricing pages on your website don’t seem to outline how the pay-as-you-go pricing will work.
Is this still being figured out?
Essentially, you pay for database queries and events, with 60'000 included for free, which is plenty for experimenting and small projects. Price per million queries/events is then based on the plan you're subscribed to, and with Starter you have zero monthly fixed costs and only pay for queries and events above 60'000. No CPU-time and similar that's usually hard to grok.
Take a look at the Accelerate and Pulse pricing details. Prisma Postgres comes bundled with these, so the pay-as-you-go pricing is the same: https://www.prisma.io/pricing#accelerate
We'll continue to make improvements to the pricing on the way to General Availability to make it both as easy to understand and affordable as possible.
If pricing is only done by storage limits, egress and query count (but not resource usage) how do you prevent something like a massive cross join with an aggregation from just running for ages on a single query?
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.
Does that mean that using Prisma Accelerate and Pulse with an external database will cost the same as using it with the bundled database? (Since I don’t see database-specific costs for storage, read replicas, PITR, backups)
While Prisma Postgres in in early access, yes. This is why there's no ability to change the database config right now.
However, when we release Prisma Postgres in GA (couple of months), you will be able to upgrade your postgres instance (CPU, storage, etc.) and that will be db-specific cost.
I recall Prism as a player in the GraphQL server field, this was about 8 years ago.
Anyone knows what happened to that? According to their website they now offer only Postgres services?
Prisma was born out of graph.cool (https://www.graph.cool/) and their GraphQL implementation became the middleware between the Prisma DB client (@prisma/client) and their Rust db abstraction layer (prisma-engine).
I believe they're getting rid of the residual GraphQL bits though, if I'm not mistaken.
Nikolas from Prisma here! I've been around for almost 8 years (since the Graphcool days) and this description is pretty accurate but I can add a bit more color. The major product evolutions we've had were:
- Graphcool: A GraphQL BaaS written in Scala.
- Prisma 1 (see [1]): A GraphQL proxy server between DB and app server. This was essentially the "GraphQL engine" of Graphcool that we ripped out and made it available as an open-source component. However, its auto-generated CRUD GraphQL API never was meant to be consumed by a frontend. Instead, it was the abstraction layer for the app server to interact with the DB (at first only for GraphQL APIs on the app server via `prisma-binding`, then the first version of Prisma Client that worked with any API layer — both of these were thin JS/TS layers that talked to the GraphQL proxy server where the actual DB queries were generated).
- Prisma 2+ aka Prisma ORM (see [3]): We realized that with Prisma 1, we were essentially competing with ORMs but that our architecture was way too complex (devs needed to stand up and manage an entire server where other ORMs could be used with a simple `npm install`). So, we rewrote the Scala "DB-to-GraphQL" engine in Rust to be able to provision it via a download during `npm install` and run it as a sidecar process on the app server, added a migration system and Prisma ORM was born. That being said, it has evolved a lot since then. We dropped GraphQL in favor of a way more efficient wire protocol [4] and have continuously reduced the footprint and responsibility of the query engine (e.g. you can now use Prisma ORM with standard Node.js DB drivers [5]).
If you want more details, I talked more about this evolution on Twitter [6] a while ago.
This launch is a huge milestone for us and it's definitely one of the most exciting launches I've been a part of at Prisma!
[1] https://www.prisma.io/blog/prisma-raises-4-5m-to-build-the-g...
[2] https://github.com/prisma-labs/prisma-binding
[3] https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea...
[4] https://www.prisma.io/blog/prisma-5-f66prwkjx72s
[5] https://www.prisma.io/docs/orm/overview/databases/database-d...
[6 ] https://x.com/nikolasburk/status/1384908813069869058
I don’t understand the free pricing tier:
$18 /million queries, 60k included
60k queries are free and then the 60_001st starts incurring costs at 18/1_000_000 per query?
> Essentially, you pay for database queries and events, with 60'000 included for free, which is plenty for experimenting and small projects. Price per million queries/events is then based on the plan you're subscribed to, and with Starter you have zero monthly fixed costs and only pay for queries and events above 60'000. No CPU-time and similar that's usually hard to grok. Take a look at the Accelerate and Pulse pricing details. Prisma Postgres comes bundled with these, so the pay-as-you-go pricing is the same: https://www.prisma.io/pricing#accelerate We'll continue to make improvements to the pricing on the way to General Availability to make it both as easy to understand and affordable as possible.
Nvm answered further down in the thread by eampiart
Our pricing for Prisma Postgres indeed presents a bit of a mental shift compared to traditional database providers:
We charge for query volume, not for compute!
We believe that ultimately this is a more intuitive way for developers to think about database cost.
Generally, our goal is that developers need to only think about _queries_ — we'll take care of everything else to make sure those queries can run efficiently. Developers shouldn't need to worry about compute, scaling, downtime, etc.
How about the scenario where I do a select … where … on a view and that view is defined to have 5 CTEs on different tables and then a final select doing some complex stuff there.
Is that billed as one query or 6?
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.
While I think as an arm-chair business wonk y’all should count it as 6 queries and not 1 as a payer and consumer I’m even more likely to use it now that you count us as only a single query. :-)
Any comparison with neon.tech?
I just answered the same questions on Twitter [1], so just quoting that:
Neon is a lot more feature-rich right now (since PPG just came out) and has awesome stuff like branching.
On the long-run, we expect to have a similar feature set. Additionally, our underlying tech has the benefits of avoiding cold starts and likely being more cost-effective.
That being said, I see it as a major benefit that with Prisma you not only get a DB but an entire data layer (incl global caching and real-time DB events) thanks to the first-class integration of our other products like Accelerate and Pulse [2].
[1] https://x.com/nikolasburk/status/1851522983346532669
[2] https://www.prisma.io/blog/announcing-prisma-postgres-early-...
https://news.ycombinator.com/item?id=41989041 combined with https://github.com/neondatabase/neon/blob/release-7011/LICEN... is a pretty stark contrast, IMHO
Congrats on the launch, this looks very interesting!
Will it ever be possible to self-host Prisma Postgres (or Pulse)? It's great that I can use your platform, but if I adopted e.g. Pulse, that's a non-trivial vendor lock in. I'd feel _much_ safer/confident building my app around the Prisma stack (besides the ORM, which I like).
Self-hosting for Prisma Postgres, Pulse, and Accelerate isn’t currently on the agenda. Our focus is on building Prisma into a company that gives developers the best tools for working with data. We handle a lot of the underlying complexity, abstracting it away to make the developer experience seamless so that teams can concentrate on building their applications rather than worrying about infrastructure—just as we do with databases and the Prisma ORM.
Your point about concerns around vendor lock-in is completely valid, and we get it. However, we're confident that our approach with the ORM, along with the trust we’ve built with the community, will set the stage for us to develop long-term commercial products that are fit for serious, production-ready deployments.
Thanks for clarification, that makes sense.
Just to give you a bit more context, I've been evaluating CDC (change data capture) tooling and Prisma Pulse was one of the options. My primary data storage is Postgres but I have a need to react when data in some tables is changed (depending on some user-provided filters). I'm currently handling that with naive message push to SQS, because Debezium/Kafka setup is too expensive/complex. Prisma Pulse looks great, but that CDC part of my app is crucial and I need an option to be able to host it myself/on premises for some customers.
However I totally understand the need to build a moat — good luck on your journey!
> because Debezium/Kafka setup is too expensive/complex
Totally get that. Many of our users like Pulse because of that.
> I need an option to be able to host it myself/on premises for some customers.
Completely understand the need and thanks for the wishes!
wow cool. Never heard about unikernels. Does it solve the issue with firecracker of not being able to reclaim memory? Would imagine that can be an issue for a long running app like a constantly busy database
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 :-)
Amazing tech! Well done Prisma team!