Just because it's cool - how does the Scale to zero Postgres for hobby projects work?

1

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.

… and this post about how scheduling works with spinning up a Fly machine when inbound requests come

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.

Why I’m asking

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.

You can see a bit more about the sustainability work going in in Wagtail, and recent analysis post modelling emissions attributable to the project.

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 :+1:

1 Like
2

Hey @mrchrisadams! Fly Postgres is open source, and you can find the scale-to-zero implementation here.

It uses the same method described in the Elixir blog post that you linked. When scale-to-zero is enabled (via an environment variable), the supervisor process (start) periodically checks whether there are any open Postgres client connections. If not, then it stops Postgres and exits. When the Machine’s main process (start) exits, the Machine shuts down.

On the flyctl side, when the Postgres Machine is created, it’s configured not to auto-restart unless it fails. Therefore, when the Machine shuts itself down, it stays down.

(It’s also worth noting that since scale-to-zero for PG was introduced, we added support for using our edge proxy to auto-stop machines, so depending on the use-case you may not need to program this logic into the app itself anymore.)

Hope this helps!

1 Like
3

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.