Postgres automatic failover, self-hosted
Most “self-hosted Postgres” setups are really just Postgres on a server. If that server goes down, so does your database, and recovery means finding your last backup and hoping it’s recent enough. That’s fine for a side project. It’s not fine once a database outage means your product is down.
Railyard treats this as a platform problem, not something every team should have to wire up themselves with Patroni, repmgr, or a hand-rolled script that watches pg_stat_replication and prays.
What a database server actually is
A database server is one of your own servers — a DigitalOcean droplet, a Hetzner box, whatever you’ve attached — that holds data and nothing else. It gets no web proxy, no build tools, and no app is ever deployed to it. Its ports are only open to the app servers that actually use it.
Add a standby when you create it (Pro and Team plans), and Railyard keeps a live, continuously-following copy of Postgres, MySQL, and Redis on a second server. You don’t configure replication yourself; it comes up automatically once both servers are online.
What happens when the primary dies
Railyard checks every standby every 5 minutes and shows you how far behind it is. If a database server stops answering for 3 minutes and its standby has independently lost contact with it too — a deliberate two-sided check, so a standby’s own network blip doesn’t trigger a false promotion — the standby takes over:
- It starts serving the data on the usual ports.
- Every app using that database server redeploys against it, automatically.
- Point-in-time recovery turns back on there.
- You get a notification listing exactly what moved.
No one has to SSH in and run pg_promote() at 3am. If you’d rather make the call yourself — the primary is still partially up and you don’t trust an automatic cutover yet — Promote by hand does the same takeover on demand, from either server’s page.
What doesn’t survive the cutover
Being honest about this matters more than the feature itself. Writes the old primary took in its last few seconds before going dark can be lost — that’s the real tradeoff of asynchronous replication, and it’s the same tradeoff every managed Postgres with a standby makes, Railyard included. Elasticsearch and a dedicated per-app Redis aren’t replicated, so they start empty on the new primary (apps reindex Elasticsearch automatically after their redeploy; a bare cache rebuilding itself is normally invisible to users).
When the old server comes back online, its dashboard page says plainly that it was replaced and that nothing is using its now-stale data. Make it the new standby copies fresh data from the new primary, so the next failure is covered too — the pair repairs itself instead of quietly running unprotected until someone notices.
Why this is different from “just use RDS”
It isn’t a replacement for a managed database if what you actually want is to hand the whole problem to AWS — Railyard supports that too, you can point an app at an external RDS, ElastiCache, or Elastic Cloud URL directly. The difference is for the much more common case: a Postgres database running on a server you own, priced at what that server actually costs, that still fails over like the managed version does. Teams moving off Heroku Postgres specifically run into this gap — Heroku’s managed failover disappears the moment you leave, and most self-hosted setups never replace it.
Protected by default also means backed up by default: every app database on a database server gets a daily backup, and each one is checked by actually restoring it, not just assumed to be good. See Database servers for the full picture, including connection pooling and Postgres upgrades, Autoscaling and failover for how this fits together with app-level failover, or database server vs. database addon for exactly when this protection kicks in versus the cheaper default.