THE MAP / RAILWAY POSTGRES BACKUP

Railway Postgres backup: the complete picture

VOLUME SNAPSHOTS · WHAT THEY MISS · OWNING YOUR COPY

Railway gives you real, vanilla Postgres with none of the platform magic — which is exactly why its backup story is the thinnest of the major hosts: the platform protects the volume, and everything database-shaped is your job. That's not a criticism; it's the deal. Here's the whole picture.

What Railway gives you natively

Why a volume snapshot isn't a database backup

A snapshot is a picture of a disk. It can't leave Railway, can't restore one table, can't be handed to an auditor, and is never verified as a working Postgres archive — you find out whether it boots when you need it to. A pg_dump archive is the database-aware version of the same idea: portable, selective, storable in a bucket you own, and — the part everyone skips — testable in advance. You want the disk picture and the dump; only one of them is yours.

The three gaps snapshots don't close

Your options, honestly

Volume snapshots alone

  • Zero setup on paid plans; fine coarse recovery.
  • On-platform, all-or-nothing, short retention, unverified.
  • Acceptable pre-revenue, or when the data is replaceable.

DIY pg_dump cron

  • Free; vanilla Postgres makes the script easy; you own the copies.
  • Silent failures, encryption, retention, untested restores — forever.
  • Honest comparison: OffsiteDB vs a cron job.

Snapshots + automated off-site

  • Keep the volume snapshots — free coarse insurance.
  • Encrypted dumps to your own S3/R2/B2 bucket, restore-drilled and row-counted.
  • Retention you set, tagged pre-migration checkpoints, monthly drill reports.

Set it up: Railway to a bucket you own

Each guide covers the Railway-specific gotcha — use the public TCP proxy URL, not the .railway.internal hostname — plus bucket setup and a one-command restore:

Doing it by hand? The pg_dump generator writes the right flags, and the RTO/RPO calculator puts numbers on your current exposure.

Five minutes to a proven copy

Paste your Railway public connection URL, point it at your bucket, and the first encrypted, restore-drilled snapshot runs in minutes. Start free, poke at the live demo, or see the restore-drill report you'd be forwarding to auditors.

FAQ

Does Railway back up my Postgres database?
Railway's backups are volume snapshots — point-in-time copies of the disk your database service runs on, available on paid plans with short retention. They can roll the volume back, but they aren't database-level backups: nothing you can download, restore selectively, or verify as a Postgres archive.
What's the difference between a volume snapshot and a pg_dump backup?
A snapshot is a picture of the disk, restorable only inside Railway, all-or-nothing. A pg_dump archive is a portable, database-aware copy: you can store it anywhere, restore one table from it, move it to another provider, and prove it restores. For recovery you control, you want the dump.
Which Railway connection URL do I use for backups?
The public connection URL (the TCP proxy host Railway exposes under Connect), not the internal .railway.internal hostname — that one only resolves inside Railway's private network, so an external backup worker can't reach it.
Do Railway's snapshots protect me from a bad migration?
Only coarsely: restoring a volume snapshot rolls the entire database back to the snapshot's moment, losing every good write since — and snapshots run on a schedule, not seconds before your deploy. A tagged, restore-tested checkpoint taken right before the migration lets you restore just the damaged tables instead.
What's the safest minimal setup for Railway?
Keep volume snapshots if your plan includes them (free coarse recovery), and add automated, encrypted pg_dump backups to your own S3/R2/B2 bucket with restore testing. The dump layer is the one that's portable, selective, provable — and survives anything that happens to your Railway account.

Keep reading