Hi @shaun! I’ve upgraded to the v0.0.34. It started showing the database size on the dashboard, though it’s a weird number. Is it the sum of sizes of all instances?
If it is, it’s not super helpful, as it doesn’t answer the following questions:
Am I running out of space on my db volumes? (currently I have 3 nodes with 15 gb volume each and db size shows 17 gb)
What is the actual size of my db?
Is it growing too rapidly? (I assume it would show up 3x inflated)
If it supposed to be like that then the metric should probably be renamed to reflect the actual meaning.
Also, it makes me wonder if other metrics are also aggregate values of all instances.
ps. Sorry for bugging that often. That’s the result of me actually relying on the service
It would be great if there was a smaller PG option with HA. Something like “Light Production” or at least if we could chose 1GB or 2GB of RAM with the custom config.
Right now it’s either a dev instance… or a full blown 3 nodes with 2x CPUs, 4GB of RAM, and 40GB of disk. It’s really overkill for apps just starting out that still need HA.
With a custom config but it’s either 1 CPU with 256MB of RAM or 2 CPUs with 4GB of RAM.
How was this promoted from a preview without WALG support? On top of that the --stolon option, at least in flyctl v0.0.495 doesn’t even work.
IMHO this change should have not only been communicated more effectively, it should never have been promoted from preview until WALG support was included. I’m now stuck in a position where I can’t implement our backup strategy on our new production cluster because proper support for backing up Postgres has been removed.
Were you able to root cause this or find a solution/workaround? The pg_replication_lag metric is empty for all of our new repmgr clusters on Apps V2 (which other than that are working beautifully). The volume size metric is working fine though.