[HN Gopher] Prisma Postgres - Runs on bare metal and unikernels
___________________________________________________________________
Prisma Postgres - Runs on bare metal and unikernels
Author : gniting
Score : 172 points
Date : 2024-10-29 14:27 UTC (4 days ago)
(HTM) web link (www.prisma.io)
(TXT) w3m dump (www.prisma.io)
| sorenbs wrote:
| 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.
| ilkhan4 wrote:
| 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.
| gniting wrote:
| 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!
| andric wrote:
| 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?
| eampiart wrote:
| 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.
| robertclaus wrote:
| 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?
| sorenbs wrote:
| 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.
| quotemstr wrote:
| I don't want limits on the kinds of queries I can run
| when those limits are artificial ones imposed to work
| around limitations of a too-simple billing system instead
| of being inherent in the domain. I'm willing to pay extra
| for the occasional huge query, but I wouldn't feel
| comfortable knowing I couldn't make it at all.
| dboreham wrote:
| That said, a production OLTP workload database would also
| have query timeout imposed, otherwise those fine folks in
| the crappy query writing department will surely bring it
| down.
| andric wrote:
| 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)
| gniting wrote:
| 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.
| thenaturalist wrote:
| You ommited another fairly known serverless Postgres provider
| which also does that (scale to 0 and no coldstart):
|
| 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.
| gniting wrote:
| Thanks for the feedback!
|
| 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.
| JamesMck wrote:
| Amazing tech! Well done Prisma team!
| iyn wrote:
| 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).
| gniting wrote:
| 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.
| iyn wrote:
| 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!
| gniting wrote:
| > 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!
| blumomo wrote:
| 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?
| halfmatthalfcat wrote:
| 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.
| nikolasburk wrote:
| 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/databas
| e-d...
|
| [6 ] https://x.com/nikolasburk/status/1384908813069869058
| victorbjorklund wrote:
| 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
| sorenbs wrote:
| 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 :-)
| ranguna wrote:
| Any comparison with neon.tech?
| nikolasburk wrote:
| 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-...
| mdaniel wrote:
| https://news.ycombinator.com/item?id=41989041 combined with
| https://github.com/neondatabase/neon/blob/release-7011/LICEN...
| is a pretty stark contrast, IMHO
| gigatexal wrote:
| 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?
| gigatexal wrote:
| > 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
| nikolasburk wrote:
| 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.
| gigatexal wrote:
| 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?
| sorenbs wrote:
| 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.
| gigatexal wrote:
| 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. :-)
| ahachete wrote:
| Last time I checked, Firecracker didn't have a very compelling
| I/O story, which made it in my opinion not completely adequate
| for running Postgres (or any other database).
|
| 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).
|
| [1]: https://github.com/cloud-hypervisor/cloud-hypervisor
| aayushshah15 wrote:
| > Firecracker didn't have a very compelling I/O story
|
| 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.
| eyberg wrote:
| The major tradeoff with firecracker is a reduction in runtime
| performance for a quick boot time (if you actually need that
| - this obviously doesn't work if your app takes seconds to
| boot). There are quite a lot of other tradeoffs too like 'no
| gpu' because that needs some of the support that they remove
| to make things boot fast. That's why projects like 'cloud
| hypervisor' exist.
| evantbyrne wrote:
| No offense but $0.09/GiB for DB read is so expensive. It sounds
| like servers would be querying Prisma over the internet? Then
| webmasters get to double pay their webhost for egress to the
| internet. Developers need to relearn how to self-host!
| gniting wrote:
| None taken!
|
| 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!
| kundi wrote:
| I find it hard to trust managing Postgres database to someone who
| decided to use CamelCase by default for the table and column
| naming in Postgres
| webstrand wrote:
| Why is that a bad thing? Otherwise you need a translation layer
| to convert to language-appropriate column names.
| jjice wrote:
| I'm not super well versed in this domain, but I believe
| Postgres columns need to be wrapped in double quotes to
| respect case, or else they're all treated as lower, or
| something along those lines?
| dboreham wrote:
| I seem to recall it's a SQL thing, not just PostgreSQL,
| although Oracle might not follow the spec. Definitely
| annoying.
| aboodman wrote:
| I find it hard to take anyone seriously who makes life harder
| for themselves for no good reason . Different strokes.
| thenaturalist wrote:
| Drizzle [0] added an easter egg on their website in response to
| this announcement it seems.
|
| [0]: https://orm.drizzle.team/
| JamesMck wrote:
| This team's ongoing, and frankly unhealthy, fixation on Prisma
| is getting so damned old (and childish).
|
| 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?
| kikimora wrote:
| How does it handles backups, read replicas, failover? And more
| importantly - how it scales with load? For example our workload
| fluctuates between 1 vCPU to 128 vCPU in an hour. How it would
| handle this?
| gniting wrote:
| During EA (early access), we don't recommend using PPG (Prisma
| Postgres) for production loads. For now (during EA), there's no
| ability to scale up the base system config.
|
| 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!
| FridgeSeal wrote:
| Nice, this is very cool.
|
| Very much of the opinion that the Unikernel stuff (and especially
| what UniKraft are offering) is being massively slept on.
| punduk wrote:
| I guess this is a different way to complicate simple things and
| sell them. "serverless database is what you need, my dude!"
| wg0 wrote:
| Congratulations! Some innovation, some engineering. The other
| way, I was thinking about using uni kernels to deploy storage
| appliances via firecracker and here we go.
___________________________________________________________________
(page generated 2024-11-02 23:00 UTC)