Started using it a few days ago and so far so good.
I haven't benchmark it yet, but overall my api response api response times have decreased from 1-2 seconds to <1 second compared with the free tier aws RDS postgres DB.
I think it's meant to signify the pricing scheme / platform type. Here, you pay for exactly what you use, and it is stored inside "projects". Meanwhile, in a "managed" scheme, you would pay a monthly fee on a per-node basis.
Practically speaking, what it translates to in this case is that your database goes to sleep when it's idle.
This means when you try to use it again, there is a cold start penalty.
You can architect your app around this a little bit, like having your web service "wake up" your database when you suspect one of your users is about to use it.
I enjoyed using Neon in a small project but the cold start was a significant penalty to the point where you might just want to send keep-alive transactions all the time, but it seems like they've made significant improvements to that earlier this year[1].
Yes, cold starts is a surprisingly stubborn problem that has many layers. We got it down to 100-200ms. Recently as we move compute from containers to VMs we starting to see more missed so we regressed it a bit.
It is theoretically possible to get it to 50ms range.
You guys have done a good job with Neon so far and ~200ms is good enough for 95% of webapp use cases (especially if devs do things like optimistically wake up the DB when a user hits the landing page or login page).
I'd be interested to see if you guys can hit 50ms without keeping more chunks of data in at least lukewarm memory. That probably comes at an increased baseline running cost for that database. Maybe customers would be willing to pay a bit extra to enable "turbo" cold starts for the databases that would benefit from it.
"Since its always going to take some amount of time to start a compute, we decided to (mostly) accept that the ongoing cost of keeping compute starts consistently fast across our entire fleet wasn’t something that we could do reliably: so we didn’t. Instead we’re (basically) always starting computes before anyone asks for them, and then when we get a request for a compute, we just take an “empty” compute, give it some configuration and… that’s it? You have a compute in a few hundred milliseconds."
That's not a cold start anymore. You just made a warm instance pool. What a waste of time this was.
> That's not a cold start anymore. You just made a warm instance pool. What a waste of time this was.
How is that a waste of time? As a customer I don't pay for the warm instance pool and the startup times from 0 are insane. AWS Aurora Serverless (v1 at least, I hated it enough I never tried v2) had startup times that took 5-10+ seconds so being able to start serving queries in less than a fraction of a second is nothing short of magical.
9 comments
[ 3.9 ms ] story [ 42.5 ms ] threadI haven't benchmark it yet, but overall my api response api response times have decreased from 1-2 seconds to <1 second compared with the free tier aws RDS postgres DB.
This means when you try to use it again, there is a cold start penalty.
You can architect your app around this a little bit, like having your web service "wake up" your database when you suspect one of your users is about to use it.
I enjoyed using Neon in a small project but the cold start was a significant penalty to the point where you might just want to send keep-alive transactions all the time, but it seems like they've made significant improvements to that earlier this year[1].
1: https://neon.tech/blog/cold-starts-just-got-hot
It is theoretically possible to get it to 50ms range.
I'd be interested to see if you guys can hit 50ms without keeping more chunks of data in at least lukewarm memory. That probably comes at an increased baseline running cost for that database. Maybe customers would be willing to pay a bit extra to enable "turbo" cold starts for the databases that would benefit from it.
That's not a cold start anymore. You just made a warm instance pool. What a waste of time this was.
How is that a waste of time? As a customer I don't pay for the warm instance pool and the startup times from 0 are insane. AWS Aurora Serverless (v1 at least, I hated it enough I never tried v2) had startup times that took 5-10+ seconds so being able to start serving queries in less than a fraction of a second is nothing short of magical.