Thanks for walking through your thinking, feedback taken!
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?
Right now during Early Access, the first hard limit would be that the database size is capped at 1GB. Of course, this will be increased as we go to General Availability.
We're also planning on shipping a way to directly connect to the database vs. operating through Accelerate queries solely.
During EA, I'd probably go with seeding from a pg dump. For GA, we'll provide a better way to move to Prisma Postgres if you're already using a pg database somewhere else.
The global caching gets even more interesting and beneficial when the end users are all over the globe, and you're caching queries that simply take longer to execute on the db. You'll save time both on latency and compute that way.
For example, everything running on the speedtest is through a single internal Accelerate project so we have some data: the overall average is 58x faster, with 779.53 ms served from origin and 13.28 ms served from cache.
Nonetheless, we absolutely have room for improvement on the ORM in terms of performance, and are working on those as well!
With Prisma Postgres, you also automatically get a connection pool and a global cache: you don't have to worry about overwhelming you db with a large number of connections, and you can add global caching to any query in just a few lines of additional code, e.g.:
```
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.
Naive, invalidation-unaware caching is a very poor hack that can work mainly for requests that are probably not your core feature, and therefore probably not your bottleneck.
So nice to hear some of you just as excited about unikernels as we are!
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.
Thanks for the list of things you'd like to see added or fixed, specifics are always much appreciated, so we can better understand!
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.
Are you folks planning on more first class postgres support? From the outside, it really seems like forcing MongoDB into the orm has forced a pretty watered down experience for the main orm (I.e. not typed SQL).
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
Indeed, as others have mentioned, you get 60k queries for free! Don't even need to add a card. Then, you rather pay for the usage (primarily by number of queries) you have.
The $49 Pro plan you mentioned gives you additional features, such as more projects, higher query limits, and a lower $$ price per million queries.
On the Starter plan though, you can get going for absolutely free, incl. those 60k queries, and only pay for the queries above that.
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!
We're working on resolving the issue, you can find and follow the latest status here → https://www.prisma-status.com/
Update: the issue is now resolved.