Since my usage is low, I set up to have my app and the postgres attached to it scale to zero when ideal. But I noticed while the app is suspended, postgres is not. Ideally, I like to see them be suspended at the same time frame. Wonder anyone else might encounter this issue or can point out the potential issue during setup.
Is this unmanaged Postgres, or managed Postgres (MPG)? For the latter, it has been confirmed in this forum that MPG does not scale to zero, since the instances are running for multiple customers.
Managed or unmanaged (or even outside of Fly), it is generally a terrible idea to autoscale Postgres clusters, unless your cluster consists of exactly 1 node without redundancy. In that case, with unmanaged Postgres you can set autostop to have it spin down when unused. But if your cluster is anything other than a single-node cluster, do not set autostop unless you want your data to disappear without warning.
1 Like
Thanks for the replies. This is unmanaged since my usage is very low and I only have a few hundred MB of data, to me it doesn’t justify to have a managed db at the moment. Maybe in the future. I have both the pg and the app auto scale down to zero because they are mostly idle at this point. pg is attached to the app. I noticed that while the app showing being suspended, pg is still running. I do see it showing suspended once a while. I thought it would make sense to have they being active or suspend at the same time. I only have one cluster due to low usage. I was using sqlite and it was fine. I switched to postgres in case I want to scale.
You may do better with the free tier of Supabase; I am using their managed Postgres offering, and it is very good indeed. You get 500MB of storage for the princely sum of nothing 
It looks like it is the case that your unmanaged PG cluster is single-node. In that case, it should be safe to set autostop = "stop" (docs) to stop the PG node when it is not being accessed by your app machine. Currently this is not set and that is why your PG node isn’t being suspended.
However, if you ever decide to scale the PG cluster up, you need to remember to unset this option before doing that, otherwise this is an almost certain way to lose your data.
Thanks for sharing your experience. I did a bit research on Supabase. Sounds liek a great idea. I didn’t more to that direction since it sounds more expansive if one scale up. Is that the case in your opinion?
I had auto_stop_machine = “stop” initially, then I see hte charge ran up fast so I switched to autostop = auto. But I will go back to autostop = “stop” since you confirmed it will work 
Thanks.
BTW, got a 404 clicking on this link (docs).
After the free tier, Supabase has a 25USD/month tier, which contains some allowances before different kinds of additional per-use costs kick in. In contrast, Fly starts at 38USD, with I think just some minimal storage charges.
You could also look at Digital Ocean, who start at 15USD for MySQL or Postgres, but there is no free tier that I can see.
I have auto_stop_machines = true in my fly.toml, which does stop the app. When I deploy hte app, I got two machines, one for the app one for pg. Will autostop=’stop’ stop both?
That’s cool. I will look into it. Do you have a good resource that can help me streamline the transition?
Not really. Vague questions can only produce vague advice, and that won’t help you much.
Are you concerned about having to move your database as your project scales up? In general you will have to stop your app, or at least put it into a read-only mode, copy the data from one database to another, swap the database configuration in your app, test the new connection, then restart your app or put it into read/write mode.
Alternatively, choose a provider where you are less likely to need to move, and then transitions will just be about paying the provider for the new usage tier.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.