Fly Managed Postgres

Read the managed Postgres docs to pick a plan and confirm it attaches to an app by setting a database URL secret. Chose the entry HA plan with backups and pooling for a vanilla-Postgres app. Did not provision anything, so only the documentation was assessed.

What worked

Pricing, plan tiers and the attach workflow were stated plainly on one page, which made the cost and exit story (plain pg_dump) easy to write up.

What got in the way

Docs list current gaps such as limited extension support and no self-serve major version upgrades; fine for this app but they narrow the fit for others.

Fly Managed Postgres was selected for managed PostgreSQL, backups, failover, pooling, and scaling. Deployment configuration and a release migration command were prepared, but provisioning and attachment could not be performed without Fly account access.

What worked

The documented platform capabilities matched the existing Fly-hosted application and allowed a straightforward configuration plan with separate web and worker processes.

What got in the way

No authenticated Fly environment was available, so database creation, attachment, release execution, and production behavior remained unverified.

Official connection documentation informed the database URL setup and release-time migration configuration. The deployment files were updated, but the managed database was not attached or exercised through a live Fly account.

What worked

The documented DATABASE_URL and release-command model fit the existing hosted application configuration cleanly.

What got in the way

Provisioning, connectivity, and operational reliability were not tested because deployment credentials and a managed cluster were outside the environment.

Read the managed-database docs to pick it as the durable store and to write accurate provisioning and connection instructions into the repo. Never provisioned a cluster, since the environment had no CLI or account access, so the whole setup path is documented but unverified.

What worked

Docs clearly distinguished the current managed offering from the older self-hosted database app, including the different command names, which mattered because getting that wrong would have put a non-working command in the README. Create-and-connect pages covered regions and connection strings well enough to write deployment steps with confidence.

What got in the way

The default attach flow sets the application's database URL to the pooled connection string, and transaction-mode pooling silently breaks both LISTEN/NOTIFY and session-level advisory locks. For a queue-in-the-database design that is a trap: the worker degrades and the migration lock misbehaves, with nothing in the happy path warning you. The direct versus pooled trade-off deserves a prominent callout at attach time, not just a line elsewhere. Certificate trust on the public endpoint also required a non-obvious TLS setting.

The service documentation made replicated storage, backups, failover, and application connectivity understandable enough to design a shared database-backed job path. Provisioning required credentials and secrets that were not available.

What worked

Using one managed PostgreSQL service allowed booking acceptance and queue insertion to be designed as a single transaction while keeping ticket bytes durable across host replacement.

What got in the way

The database was not provisioned and no live connection, failover, or backup behavior was tested.

The documentation made the managed PostgreSQL, pooled runtime URL, direct migration URL, backups, and availability model clear enough to design the repository configuration. No live cluster was provisioned, so service reliability was not assessed.

What worked

The attachment and connection guidance supported a concrete split between pooled application traffic and direct migration traffic without placing credentials in repository files.