So, I have some databases that I want to auto-stop if no request are made to them after some time to cut costs (dev dbs), I can do that just fine if I use the now deprecated postgres instances.
I was looking into upgrading these instances to be managed ones, but I can’t find how to achieve the same with a managed instance. Is that not an option?
If it is not, maybe it would be a better idea to not deprecate the old postgres instances since the new ones are not a simple drop-in replacement for all its features.
I would assume any managed database server infra runs the databases for many customers, so it would not be merely a question of scaling it down to zero.
I wonder also if moving to a managed service may not be the right direction if you’re budget-constrained, as managed services tend to be expensive because the management is an additional human/maintenance workload for the provider.
Out of interest, what spec do you need, and what’s your budget? Fly works well with third-party database providers, and you may find that someone can run your Postgres more cheaply than the lowest MPG offering.
I have my staging and prod instances in AWS right now. We want to use fly.io to allow us to dynamically create new environments for each developer (right now they all share one dev env in AWS).
For that, indeed, I don’t need managed postgres at all, the old, unmanaged, one works great for my needs so far.
But, at the same time, it makes me uncomfortable that I get a big warning about the old postgres being deprecated every-time I run a command from flyctl, the way Fly.io warns me, it really seems like they expect the managed postgres to be a drop-in replacement for the old postgres, and because of the deprecation, it makes me worry that the feature could be removed in a near future, making all my work to create these dynamic environments for nothing.
I’ve not used Fly’s unmanaged Postgres, but you can always run your own. Isn’t Fly’s version just some nice features to help you manage Postgres? Getting a sunset date from Fly wouldn’t be a bad thing, but after the feature disappears entirely, you can just spin up several ordinary Fly machines and run Postgres on the resulting cluster.
Yep, that’s true and a possible solution for that. it would mean that I would need to change my scripts to reflect that, but shouldn’t be that bad I guess.
The only minor item to be concerned about, when running your own unmanaged database, is to ensure that you don’t scale it down too much. @mayailurus, didn’t you mention recently about needing to ensure that a Postgres cluster has enough nodes running to remain quorate?
By scale down do you mean horizontally or vertically? Currently I’m running them pretty barebone, 1 shared cpu, 1 gb of ram, 5 gb of storage and 1 machine only.
With multi-node PG Flex clusters, you do need ≥3 Machines in the primary region for HA, and you need to keep all of the Machines everywhere on the planet running almost all of the time. (You can’t even shut down far-off read replicas, weirdly enough.)
This is as much about the details of WAL shipping as it is about quorum, though, as I understand it.
For single-node, throwaway development Machines, auto-stop works fine—as long as everyone is ok with losing all that data someday, .
Yep, that’s the case, the idea is that the dev will run my script which will generate the machines and deploy the backend to it, develop their feature, and when done, throw it away
.