Railway databases are unmanaged services

I do not have to argue this one. Railway's database reference docs call the templates "unmanaged services" and then spell out, in their words, what you are responsible for:

configuring backups and disaster recovery

tuning performance

managing security and access control

monitoring and maintenance

That is an unusually honest list to put in your own documentation, and I want to give credit for it before I spend a thousand words on what it means. Most platforms let you infer the support model from the absence of a page. Railway wrote it down.

The problem is where the sentence sits. It is in the reference docs, and the deploy button is on the dashboard, and the deploy button is what you actually experience. You click Postgres, a database appears with a DATABASE_URL wired into your service, and it feels exactly like the managed thing. The word "unmanaged" is doing enormous work in a place you will probably never read.

Unmanaged is a design, not an accusation

Railway's databases are templates: a container running the official image, with a volume attached and networking wired up. PostgreSQL, PostgreSQL HA, MySQL, Redis, and MongoDB are first-class templates. ClickHouse, CockroachDB, TimescaleDB, InfluxDB, Neo4j and plenty more come from the marketplace or a Docker image you point at yourself.

For a platform whose entire pitch is "deploy anything from a repo or an image," that is the consistent choice. It also means the engine you get is the engine upstream ships, with no vendor fork or protocol shim in between. If you want to run something obscure next to your app, Railway will do it happily and most managed hosts will not.

What you are buying is a scheduler, a volume, and a network. What you are not buying is somebody else's pager rotation. Four consequences follow, and only the first is obvious.

The four things you now own

Backups and disaster recovery. No schedule exists until you build one, and "we have a volume" is not a backup, because a volume with a bad DELETE in it is a faithfully preserved bad DELETE. This is the one people find out about in the worst possible way. Wire up pg_dump to object storage on a cron on day one, and test a restore, because an untested backup is a rumor.

Tuning. Default shared_buffers, default work_mem, default connection limits, whatever the image ships. Your app gets slow at 3x traffic and the reason lives in a config file nobody has opened.

Security and access control. Roles, password rotation, who can reach what. There is no per-database IP allowlist documented at the TCP proxy level, so exposure is a function of whether the proxy is on.

Monitoring. Container metrics, yes. Database metrics like table bloat, replication lag, long-running queries, connection saturation: yours to instrument.

None of that is hard, individually. It is just work you did not price in, and it is work that never appears until the week it appears all at once.

Three structural gaps, and the guardrail

Beyond the ops list, three things are missing for a specific reason, and I want to be precise rather than dramatic about each.

There is no database branching. Railway's PR environments duplicate your services and inherit the base environment's variables, which means the preview deploy points at the same DATABASE_URL as the environment it forked from unless you go wire up a second database yourself. That is fine for a static site. It is not fine for a pull request that runs a migration, and the failure mode is that the migration runs against the shared database and everyone's afternoon is now about that.

There is no HTTP query API. Database access is raw TCP through the TCP proxy, billed as egress. Railway does publish a GraphQL API, but it is the platform control plane: it deploys services, it does not run your SELECT. If you have workloads on an edge runtime that cannot open a socket, this is a wall rather than a nuisance.

The TCP proxy terminates no TLS. Their docs put it this way: the TCP proxy "currently does not support attaching custom domains or SSL certificates." So whatever encryption you get between your laptop and that Postgres is whatever the container itself was configured to do. Not "insecure" by default, but definitively not the platform's job.

And the guardrail, because I have seen this claimed wrongly in other comparison posts: Railway does have a free plan. $0 a month with $1 of monthly usage credit, capped at 1 replica, 0.5 GB of RAM, 1 vCPU and a 0.5 GB volume, plus a separate 30-day trial carrying $5 of credit and needing no card. Anyone telling you Railway killed its free tier is describing a different platform.

The meter runs per second

Railway bills pure usage, per second: $0.00000386 per GB-second of memory, $0.00000772 per vCPU-second, $0.00000006 per GB-second of volume, and $0.05 per GB of egress. Hobby ($5/mo) and Pro ($20/mo) are credit-bearing floors per workspace, not ceilings.

I actually like per-second metering as an idea. It is honest about what a container costs, and it is why an idle service on Railway is genuinely cheap. The catch is the one every metered platform shares: a database is the service in your stack that is never idle in the way you hope. It holds connections, it runs autovacuum, it keeps a volume. And a per-second meter with a floor and no cap means the only way to answer "what does this cost next month" is to predict your own traffic. I wrote about what that adds up to across a whole stack in the multi-database tax.

What managed actually buys, stated as specifics

I run Layerbase Cloud, which is a managed database host and not an app platform, so this is a comparison of one half of Railway rather than the whole thing.

Concretely, the four items from Railway's own list are ours: backups run on a schedule with 7-day retention on Solo and 30-day on Pro, engine configuration is tuned per engine and per plan rather than left at image defaults, TLS is terminated for you with a per-database IP allowlist available on every plan including Free, and health monitoring is what pages me rather than you.

The three structural gaps have concrete answers too. Branching works on 9 engines, so a preview environment gets its own copy of the data instead of a shared connection string. The HTTP query API covers 17 of the engines we host, which is the piece that makes an edge runtime workable. And pricing is flat: Free is $0, Solo is $5/month, Pro is $15/month, with no meter on queries, connections, or egress on any plan. If you outgrow the included capacity it grows in $10/month blocks, which is a number you choose rather than a curve you forecast.

Where Railway wins and I will not pretend otherwise: your app and your database come up together with one push, private networking between them is free and instant, and if the engine you need is a Docker image nobody manages, Railway runs it today.

The split most people actually want

This does not have to be a migration away from Railway. The common shape is: keep deploying the app on Railway, move the database out. You lose the free private-network hop between them and you gain a database somebody else is on call for. Whether that trade is worth it depends entirely on whether you have already had the bad night.

If you want to try it, layerbase.com/migrate/railway does the copy from a single Railway token: it lists your Postgres, MySQL, and Redis services, you pick one, and it reads it once into a matching managed database with nothing written back. The step-by-step version, including what changes in your connection handling, is in migrating a Railway database to Layerbase.

Or start from scratch on the free tier and point a staging environment at it for a week. That is the cheapest possible way to find out whether "unmanaged" was costing you anything.