Prisma Postgres – Runs on bare metal and unikernels
prisma.io
prisma.io
My $5 VPS can handle more queries in an hour. Like, I realize there’s more included, but…
Is it truly impossible to serve this stuff somewhere closer to cost? If this is close to cost, is this truly as efficient as it gets?
The pricing you are citing is for Accelerate, which does advanced connection pooling and query caching across 300 POPs globally.
All that being said, we'll def address the "can you pls make Prisma Postgres pricing simpler to grok?" question before we GA this thing. Thanks for the feedback!
more here: https://www.prisma.io/docs/accelerate/connection-pooling
also recommend trying out the Accelerate speed test to get a "feel for it": https://accelerate-speed-test.prisma.io/
Nonetheless, we absolutely have room for improvement on the ORM in terms of performance, and are working on those as well!
I rationally realize there is a price/usage point where this makes sense, but emotionally it doesn’t feel good.
Start the plan at $59 and include 2M queries.
All that being said, if there are specific questions that you have which relate to a use case, ask away!
Prisma announced Accelerate on January 16, 2023
But you are right, they are close in functionality though Hyperdrive requires a CF Worker to operate.
1) 60k queries? I burn through that in an hour. All it takes is the Google bot and some shitty AI scraper to come along and crawl our site - which happens every single day.
2) $18 per million? I don't know how many queries I need per day, at the moment, but give 1), I will surely burn through a million dozens of times oer months...
...at which point this thing will be just as expensive as an RDS instance on AWS, potentially even more so if we hit traffic peaks (every single user causes hundreds of queries, if not thousands).
3) I don't even understand who to interpret the egress cost. No idea how to predict what the pricing will be. Maybe some calculator where we can slot in the relevant estimated values would be nice?
What's your take on the pricing calculator? We've been working on an improved version, and would love to hear your thoughts on this. In your case, what inputs would you find helpful to put in to arrive at a calculation, considering that you're unsure about projecting both queries and egress? How would you go about putting in estimated values for those?
I don't know why people ever buy plane tickets, walking's free.
With the Prisma pricing, $1k gets you up to a 48req/s load average, and that's without the geo balancing. For a little more you can get a dedicated Postgres instance with 128GB memory and 1TB+ of disk on DO that would definitely handle magnitudes more load.
Of course there are a bunch of trade-offs, but as the original poster said the gap is pretty wide/wild.
The point is that when I buy managed postgres, the thing I expect to be paying for is, well, postgres. Not a bunch of geo load balancing that I’m never going to need.
That’s why the comparison is with the thing that actually does what I want.
Honestly I'm surprised they lasted this long.
For example, I used Aurora Serverless v2 in a deployment, and eventually it just made sense to use a reserved instance because the fee structure doesn't make sense.
If I actually scale my app on these infrastructuers, I pay way more. I feel it's only great for products that _arent_ successful.
Bingo. The pricing alignment makes sense:
You share the risk of idle, but provided capacity with the provider: no fixed capacity for no fixed pricing.
The capex for the provider are fixed, though.
That's why I think more competition in the serverless Postgres space is fantastic: Sure, it's not a pure price competition, providers try to bundle with slightly different customer groups they focus on.
But underneath it, technology is being built which will make offering serverless ever more cost effective.
We might see a day where serverless (i.e. unbundeled storage and computed) with dedicated compute is cheaper than standalone GCP/ AWS/ Azure Postgres.
I saw them hiring Rust devs recently, which makes me feel like they do things efficiently(hopefully). That being said, Serverless is the greed-driven-model, where you start by thinking, "meh, we don't need that many queries/executions/whatever anyways, we will save plenty mulas we'd waste otherwise renting a reserved instance sitting idle most of the time", then something bad happens and you overrun the bill and then go into "sh+t, need to always rent that higher tier, else we risk going bankrupt" and since your stuff is already built, you can no longer change your stuff without another big re-write and fear or breaking things.
With most of these serverless providers, there's no technological lock in I am aware of, it's all just Postgres features paired with DevOps convenience.
We are also working on making this simpler to understand. We want to make sure our pricing is as easy to grok and as affordable as possible. Keep an eye out for improvements as we get to GA!
60k are included.
But, I totally agree to your overall statement. The premium for hosted DBs is quite high despite the competition.
Usually, if you want hardware to handle real world production data volumes (not 1 vCPU and 512MB, but more like 4 vCPUs and 8G) you are very soon around $200 to $300. A VPC with that size is around $15?
The hosted solutions are just so damn easy to get started.
Often these types of SaaS are hyper cloud backed so their own costs tend to be high
Don’t know whether that’s the case here. Agreed though that pricing also raised my eyebrows
OS' are pretty stable these days, and you can containerize on your server to keep environments separate, and duplicate
I guess it just comes with experience, but at the same time, the devops skillsets necessary for dealing with serverless stuff is also totally out of this world. most places I've worked at, marketing hasn't even launched a campaign, there is no product validation about how much traffic you'll get, and you're optimizing for all this scale that's never going to happen
I do hope tomorrow's engineers won't have to learn devops to use the cloud. My team works on what we think is the better way to do serverless, check it out! https://dbos.dev/
However, the SQL standard prescribes the case to be folded to uppercase, while PostgreSQL folds to lowercase.
The original root cause was having schemas backed by directories, and table definitions backed by .frm files. So on a case-insensitive filesystem like on Windows or MacOS, MySQL enables corresponding case-insensitivity logic for the affected types of identifiers.
For a deeper dive, see my post https://www.skeema.io/blog/2022/06/07/lower-case-table-names...
CREATE TABLE CamelCase(...)
SELECT * FROM "CamelCase";
That's because the CREATE TABLE statement creates a table named "camelcase", not "CamelCase", despite what you might assume from the query.
No bit seriously, thanks for sharing. I'll always do lower case table names from now on.
You can quote the table name in the create statement to get the camelcase table name. Just remember to quote in both creation and usage or neither, is a good rule of thumb
I did contract work for a large international financial institution, known for being "one of the big N" (N<5). Lots of data/backend/db work, in several languages/stacks. Then a new style/naming convention for databases got pushed, by middle/higher management. It included identifiers in both camel-case and pascal-case. It was clearly "designed" by somebody with a programming background in languages that use similar conventions.
I noticed how there would be trouble ahead, because databases have (often implicit) naming conventions of their own. Not without reason. They have been adopted (or "discovered") by more seasoned database engineers, usually first and foremost as for causing the least chance of interoperability issues. Often it is technically possible to deviate from them (your db vendor XYZ might support it), but the trouble typically doesn't emerge on the database level itself. Instead it is tooling and programming languages/frameworks on top of it, where things start to fall apart when deviating from the conventional wisdom of database naming conventions.
That also happened with that client. Turned out that the two major languages/frameworks/stacks they used for all their in-house projects (as well as many external product/services), fell apart on incompatibility with the new styling/naming conventions. All internal issues, with undocumented details (lots of low-level debugging to even find the issues). I already had predicted it beforehand, saw it coming, reported it, but got ignored. Not long after, I was "let go". Maybe because of tightened budgets, maybe because several projects hit a wall (not going anywhere, in large part because of the above mentioned f#-up). I'm sure the person who original caused the situation still got royally paid, bonuses included, regardless.
Anyways, the moral of the story here is this: even if you technically could deviate from well established database naming conventions, you can get yourself in a world of hurt if you do. Also if it appears to resolve naming inconsistencies with programming languages of choice.
(I say that with appreciation -- I always think of the former as UpperCamelCase because I never used Pascal)
Welcome to quoting everything for the rest of your query life.
I guess they were busy working on this instead... for now.
An engine that doesn’t allow you to set per-connection settings effectively is pretty crazy IMO.
Then you can pass `statement_timeout` when you create the `pg.Pool`
With close to 400K monthly active developers using our library and over 9M monthly downloads on NPM, one can imagine that the issues keep piling up!
To be fair this kind of makes sense, especially when the thing that makes many tasks difficult is finding solutions that don't break existing usage.
That's unnecessary moving part IMHO. Is it still the case or they changed their architecture recently?
There were ample reasons in the past whereby going down this path made architectural sense. The primary one being multi-language support. Since then, TS and JS have found their way to the top of "the programming langs of choice" charts and so we're digging into removing the Rust based components and making them optional.
We'll share more on this in the coming weeks.
Partly this is what makes this a fun and interesting challenge that goes beyond just the tech and the team is eager to get their hands dirty to solve this. For now, lots of ideas on the board. Once we have a plan, we will start to share in order to get community feedback.
Dropping the rust client will solve another big complaint. I definitely feel the issues languishing problem. I've submitted a few confirmed reproducible bugs that have hung out for a couple years. Still, I'm happier with their recent direction than I would have expected.
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.
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.
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?
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.
- 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.
Companies, especially smaller ones starting out, will run analytics in the same DB as the application DB.
A major plus of using a Postgres DB is the flexibility of doing analytics and serving apps. It can do it all. Analytics queries will often easily exceed your timeout limits.
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.
Nile (thenile.dev).
Not affiliated in any way with Nile, just a happy user.
I find their pricing much easier to reason about and plan, something I found super cluttered and hard to reason about on your pricing page.
Competition in the serverless Postgres space is always welcome from a customer perspective, but my gripe is currently a) bundling with Prisma - I might not want to use your tool and b) cluttered pricing.
The point re: pricing explanation is well taken. We've already done a revision and will work on another one as we get more feedback on the latest version.
In any case: Best of success in bringing this to GA, it’s great you’re among teams working on making this accessible!
Historically, we haven't been very good at explaining how we pick the issues we work on. That is being addressed and you'll soon see us share our process transparently. This will allow everyone to better understand how we're going to continue improving the Prisma ORM.
I don't know if it's true, but it seems like you're be able to address the backlog more easily of you didn't have to force abstractions that work for a no SQL db
However, when we roll out the service in GA, you'll be able to "upgrade" the base system and one of the plan tiers will support autoscaling along the lines of what you've described.
The EA launch is for us to get PPG into the hands of our users and to vehemently listen to requests/requirements/bugs... your request has been noted and thanks for raising it!
In contrast, other similar VMM seem to have a better one, like Cloud Hypervisor [1]. Why then FC and not CH? (I've nothing against FC, actually love it and have been using it, but it appears not being the best I/O wise).
Can you provide any sources for this claim? We're running Firecracker in production over at blacksmith dot sh and haven't been able to reproduce any perf regressions in Firecracker over CH in our internal benchmarking.
Very much of the opinion that the Unikernel stuff (and especially what UniKraft are offering) is being massively slept on.
Hugely impressive.
A little weird that they say "no cold start" versus... "minimal cold start".
Cold starts in milliseconds != no cold starts, though I get it -- marketing is marketing and it's not wrong enough to be egregious :)
That said, super excited that someone has built a huge complex database like Postgres on Unikraft.
Been a while since I kicked the tires on Unikraft but looks like it's time to do it again, because this isn't the only software that could use this model, given an effective unikernel stack.
Re: zero/minimal cold-start... Technically, you're right, though I'd say if you don't notice it's there, it's as good as not even being there. :) You get the pragmatism though, appreciate it.
Lots of cool stuff coming for Prisma Postgres that all this tech enables, looking forward to keep telling you all about them.
Anyone knows what happened to that? According to their website they now offer only Postgres services?
I believe they're getting rid of the residual GraphQL bits though, if I'm not mistaken.
- 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...
Right now super fast start times aren't really needed since it's a database that I expect to be running for a while - ms vs 30s is fine. It's easier to setup a test database on the same machine I'm running automated tests so that may not be a good usecase either.
I'm glad that they've made improvements to startup speed and size of the containers which would be good if it's open sourced, but I don't know if this is good as a paid service if you already have an easy way of setting up new clusters in k8s.
``` const user = await prisma.user.findMany({ cacheStrategy: { swr: 60, ttl: 60 } }) // <--- set a cache strategy in really just a single line ```
Both of these are super important when serving users that are spread across the globe. Latencies between regions add up. If you're curious, check out https://accelerate-speed-test.prisma.io/
Similarly enabled already on the db, you can subscribe to any change happening to your db, e.g. to send out welcome emails when a new user is added to the User table. Makes event-driven architectures super easy. Take a look at Pulse, which comes bundled with Prisma Postgres: prisma.io/pulse
Another benefit of a managed service of course is that you don't have to worry about managing any of it. Things happen, traffic spikes, servers go down, for a lot of us, that's nice to not worry about and rather focus on building and shipping the things that make our own products and services unique. Also, in a lot of situations, provisioning something complex is just not worth it, and a quick deployment to try or test something is desired.
My first opinion wasn't very far from yours, but then I adopted it. It has served me well after a year and multiple projects.
$18 /million queries, 60k included
60k queries are free and then the 60_001st starts incurring costs at 18/1_000_000 per query?
Nvm answered further down in the thread by eampiart
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.
Is that billed as one query or 6?
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.
Let's say I have a ~150GB postgres DB right now and I want to move it to Prisma Postgres. At 1kb/request and $8/million requests, does that mean 150 million requests billed at $1200 just to get started?
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).
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!
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!
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-...
The intention is clearly not to have any double dipping, so the verbiage and presentation of the pricing elements needs to improve... and it will! The feedback regarding clarity on pricing is well received. We've know that we've got some work on our hands along those lines and we're working to address it. Stay tuned!
> always-on database with pay-as-you-go pricing for storage and queries (no fixed cost, no cost for compute). It's like a serverless database — but without cold starts and a generous free tier
The "secret" sauce probably. Firecracker is so cool.
I don't know what this means, but setting up a PostGres DB is a single PSQL command, or a few clicks in PgAdmin.
It's rare to witness a group so openly attempt to undermine another, while simultaneously drawing on the very same team’s ideas to inform their own product direction. Despite repeated public feedback calling out this unprofessional behavior, there appears to be little desire for growth or maturity.
Kudos to the Prisma team for consistently upholding a high standard of professionalism by ignoring them.
Wondering why you posted this... do you condone such childish behavior?
I have no affiliation with any provider/ name/ person in this space.
I condone making premature judgements.
I have no clue about Drizzles behavior and the only thing I learned about Prisma in the last two weeks is that they have their own schema definition language, a separate Rust proxy and seemingly didn’t address open feature requests for a couple of years which is why for now I didn’t pick them in my project.
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 :-)