# Railway makes Postgres recovery, HA and pooling machine-operable from its CLI Railway's CLI can now manage Postgres high availability, point-in-time recovery and PgBouncer directly, including JSON output for automation. The database features are not all new; the material change is that recovery and failover operations are now scriptable instead of dashboard-bound. Agents and operations tooling can inspect HA health, trigger switchovers, restore to a timestamp and change connection pooling from one machine-readable surface. That increases automation power, but recovery actions still create real operational boundaries such as brief failover interruption and forked PITR services. - Status: Active - Published: 2026-09-06T14:37:17+12:00 - Updated: 2026-09-06T14:37:17+12:00 - Categories: Web Development, Cloud & Infrastructure, Deployment & DevOps, Developer Tools, Databases & Storage - Tags: CLI automation, high availability, PgBouncer, point-in-time recovery, PostgreSQL, Railway - Canonical HTML: https://beyondthe.news/dossiers/railway-postgres-cli-ha-pitr-pgbouncer-automation ## What changed Railway added first-class Postgres operations to its CLI on September 4, 2026. New commands cover HA conversion and health, node scaling and primary switchover, point-in-time recovery status and restore operations, backup scheduling, and PgBouncer configuration. Commands support project/environment/service targeting and JSON output, making the same controls usable by scripts and agents rather than only through the web dashboard. A PITR restore creates a separate service and preserves the original source database; an HA switchover can briefly interrupt active connections. ## Why it matters Database recovery controls are unusually consequential automation primitives. Exposing them through a CLI means infrastructure agents, runbooks and CI/operations systems can inspect and act on database state without browser automation. That can shorten recovery workflows and make configuration reproducible, but it also raises the bar for permissions, confirmation and idempotency: a machine can now trigger operations that move primaries or fork production state. ## HA operations are now scriptable Railway's Postgres CLI can inspect HA status, convert eligible deployments, manage nodes and switch the writable primary. Applications still need reconnection handling because a switchover can produce a short interruption. ## PITR restores fork rather than overwrite the source Operators can enable, inspect and restore point-in-time recovery from the CLI. Railway's current recovery model creates a new service from the selected point, preserving the source database instead of destructively rewinding it in place. ## Pooling joins the same control surface PgBouncer configuration can also be managed through the CLI. That makes connection pooling part of the same automation path as recovery and availability rather than a separate dashboard-only task. ## JSON output makes the feature agent-friendly Machine-readable output and explicit project/environment/service selection make it practical to build checks and recovery workflows around the CLI. Teams should still put destructive or topology-changing actions behind scoped credentials and human approval where appropriate. ## Key details - Railway announced Postgres CLI management on September 4, 2026. - CLI commands cover HA, PITR and PgBouncer. - HA operations include status/health and primary switchover controls. - PITR restore creates a new service while preserving the source database. - Railway documents roughly four weeks of PITR retention in the current implementation. - PITR uses PostgreSQL recovery tooling and stored WAL/backups; storage and egress can be billable even when there is no separate PITR feature fee. - CLI JSON output supports automation and agent consumption. - HA switchovers can briefly interrupt database connections. ## Builder takeaways - Use JSON status commands for monitoring first before allowing automation to trigger switchovers or restores. - Gate topology-changing database commands behind narrowly scoped credentials and explicit approval in agent workflows. - Test client retry/reconnect behavior before automating HA switchovers. - Treat PITR restore as a forked recovery workflow: verify the new service, then decide how application traffic should move. - Record the exact project, environment and service targets in runbooks so an automation cannot act on the wrong database. ## What to watch - Whether Railway adds non-interactive confirmation controls designed specifically for agents/CI. - More granular database-operation permissions or audit events. - Support for the same CLI recovery surface across MySQL or other managed databases. - Changes to PITR retention, billing or restore-time guarantees. ## Uncertainties - The operational safety of these commands depends on account permissions and surrounding runbook design. - A CLI surface does not make failover or recovery zero-downtime. - Current retention and billing details can change as Railway evolves its database product. ## Sources - [Postgres in the Railway CLI](https://railway.com/changelog/2026-09-04-postgres-in-the-railway-cli) — Railway · primary changelog · 2026-09-04T00:00:00+12:00. Primary announcement of HA, PITR and PgBouncer CLI controls. - [Railway CLI](https://docs.railway.com/cli) — Railway Docs · primary documentation. Current CLI usage and machine-readable automation surface. - [Point-in-time recovery](https://docs.railway.com/volumes/point-in-time-recovery) — Railway Docs · primary documentation. Current recovery behavior, retention and restore semantics.