I’m aware that Fly.io has a scale to zero database offering for postgres. I’m referring to this here:
Are there plans for any blog posts to explain how it works?
Based on this except form this recent blog post:
If you’ve ever wanted to shut down an application when no one’s connected to it, say for demand-driven horizontal scaling using Fly Machines, then we have the perfect little recipe for you. At the time of writing, “regular” Fly apps don’t run on Machines, so you can’t use this to scale.
When a Fly Machine is in a stopped state, you’re not using RAM or CPU, so you pay only for storage.
At this point, what we’re asking our scheduler to do is to consider Docker images themselves to be a resource, like disk space and memory. The set of images cached and ready to deploy on any given server is changing every second, and so are the scheduling demands being submitted to the orchestrator
Source: Carving The Scheduler Out Of Our Orchestrator by @flydotio
My guess is that both apps and db servers might scale down to zero when there are no connections detected - so a postgres server instance is spun down after the last db connection has been closed after a given amount of time.
I’m mentoring some folks on the Wagtail project to create some guidance on greener coding techniques, and I want to refer to the approach Fly takes as a pattern to look for when choosing a host.
Also, an example of some relevant work we completed so far in this field, we recently added AVIF support to the 5.1 release, for smaller images -
Anyway, you can follow along in the github open project, and there are two tickets we plan to flesh out into some documentation inside Wagtail, for scale to zero options - at the app side , and on the database server side.
It would be really cool to write about some of the scale to zero options with Fly, but it would likely be more accurate if we had input from people more familiar with the infra, so we’re not misrepresenting anything.
Anyway, I hope that provides some useful context