4 ms·
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
by 22c 3y ago
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].
1: https://neon.tech/blog/cold-starts-just-got-hot https://neon.tech/blog/cold-starts-just-got-hot
- nikita 3y agoYes, 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.
- 22c 3y agoYou 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.