Skip to main content
Important: We are not able to provide support or guidance for unmanaged Postgres. We now offer Fly.io Managed Postgres , our fully-managed database service that handles all aspects of running production PostgreSQL databases.
When you created your Fly Postgres cluster, Postgres configuration parameters were set to reasonable defaults for your VM resources. flyctl exposes some of these parameters so you can tune them to your application’s needs, or to match any VM scaling you do. Before you start tuning, it’s important to understand the tradeoffs that you’re making. Choose values for these parameters with the guidance of the Postgres docs.

​
View current configuration

View your cluster’s current configurable settings with fly postgres config show:
(The shared-buffers value is indeed in units of 8kB, so a value of 8192 corresponds to 64MB of RAM that Postgres will use for shared buffers.)

​
Update configuration settings

To demo how this works we’ll update the max-connections setting from 300 to 500 using fly postgres config update.
Each VM belonging to your Postgres app will be restarted to apply the changes. If you have a replica for high availability, this is updated and restarted first, and it becomes leader before the old leader gets updated. We can take one last look at our config show and see that our max-connections value has now officially been applied!

​
Gotchas

If you mismatch Postgres parameters and VM RAM, you may end up with an unhealthy cluster and errors like this in your logs (these are from an older Stolon-managed cluster):
If you’re scaling your instances up, do that before adjusting the Postgres config to match. If you’re scaling down, adjust the cluster’s Postgres parameters to match the reduced resources before scaling the VM.