One-click databases, and why persistent volumes matter for them
Databases & SQL's own domain taught how a relational database actually works. This lesson is about a narrower, very practical question: what does it actually mean to run one as a "service" on a platform whose other services are designed to be disposable and endlessly replaceable?
Intermediate
2 min read
Provisioning a database as just another service
Railway dashboard → "New" → "Database" → "PostgreSQL"
→ a running Postgres instance, with a connection string,
appears as a new service in your project within seconds
Adding a managed Postgres, MySQL, Redis, or MongoDB instance to a Railway project takes the same "add a service" action as deploying your own code — no separate database-hosting account, no manual server provisioning, and it automatically gets a private network hostname (lesson 4) other services in the project can reach immediately.
The real tension: containers are disposable, databases can't be
Docker & Containers' own domain established that a container's filesystem is disposable by design — restarting or redeploying a container normally means starting fresh. A database obviously cannot work this way; its actual data has to survive container restarts, redeploys, and even the container moving to different underlying hardware. A persistent volume is storage that exists independently of any one container instance — Railway automatically attaches one to every database service it provisions, which is exactly what makes "one-click database" actually safe to use for real data, not just a toy demo that loses everything on the next deploy.
Backups: a volume surviving a restart isn't the same as surviving real disaster
A persistent volume protects against the ordinary container lifecycle (restarts, redeploys) — it does not, on its own, protect against a volume itself becoming corrupted, an accidental DROP TABLE, or a region-level outage. Railway's managed databases include automated backups specifically because "has a persistent volume" and "is actually backed up" are two different guarantees — the same distinction this curriculum's own AWS domain draws between RDS's storage durability and RDS's separate, explicit backup/snapshot feature.
Connecting to a Railway database from outside Railway
railway connect postgres # opens a local psql session through a secure tunnel, # without exposing the database publicly at all
Because Railway databases default to private-only networking (lesson 4), reaching one directly from a local machine for debugging or a one-off migration uses the Railway CLI's tunnel, rather than exposing the database's port to the public internet just to run a few manual queries — preserving the same default-private security posture lesson 4 established, even for ad hoc developer access.