Railway databases are unmanaged. Railway says so.
Short version: Railway's own database reference docs call its database templates "unmanaged services" and then list what you are responsible for: backups and disaster recovery, performance tuning, security and access control, monitoring and maintenance. That is a coherent design for an app platform rather than a scandal, but it is not what the one-click Postgres button leads you to expect. On top of the ops list, there is no database branching, no HTTP query API, and no TLS on the TCP proxy. Railway does still have a free plan, whatever you have read elsewhere.
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 and 1 vCPU / 0.5 GB of RAM per service, 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.
Railway plan prices, free-plan caps, and per-second rates verified 2026-08-26 from railway.com/pricing.
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 16 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.
FAQ
Are Railway databases managed?
No, and Railway says so in its own reference docs, where the templates are called unmanaged services. You get a container running the upstream image with a volume and networking attached. Backups, tuning, access control, and database-level monitoring are yours.
Does Railway back up my Postgres automatically?
There is no schedule until you build one. A volume is not a backup, because a volume with a bad DELETE in it is a faithfully preserved bad DELETE. If you are running a Railway database today, wire pg_dump to object storage on a cron and then actually test the restore.
Can I give each pull request its own database on Railway?
Not without building it. PR environments duplicate your services and inherit the base environment's variables, so the preview deploy points at the same DATABASE_URL as the environment it forked from unless you provision a second database by hand. That is fine for a static site and bad for a pull request that runs a migration.
Does Railway still have a free tier?
Yes. $0 a month with $1 of monthly usage credit, one replica, and a 30-day trial with $5 of credit that needs no card. The claim that Railway killed its free tier keeps circulating in comparison posts and it is wrong.
Why does a per-second meter matter for a database specifically?
Because a database is the service that is never idle in the way you hope. It holds connections, it runs autovacuum, it keeps a volume. Per-second billing is honest about what a container costs, but with a credit floor and no cap, answering "what does this cost next month" means predicting your own traffic.
Can I keep the app on Railway and move only the database?
That is the common shape, yes. You give up the free private-network hop between app and database, and you gain a database somebody else is on call for. layerbase.com/migrate/railway reads a Railway Postgres, MySQL, or Redis service once from a single token and writes nothing back.
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.
Keep reading
- Preview environment platforms in 2026: what is in the database when the preview comes upEvery platform on this list will give a pull request its own URL. The question that sorts them is what is in the database behind that URL: nothing, a restore of last night's backup, or the live data as of right now. Here is where each of eleven platforms lands, quoted from their own docs, and what a preview costs while the PR sits open.
- Northflank alternatives: a preview environment is not a database branchNorthflank gives every pull request its own stack, and the database in that stack starts empty unless you seed it or restore it from a backup you already had. Here is exactly how their forks work, what a copy-on-write branch does differently, what each one costs while a PR sits open, and the cases where Northflank is the right answer.
- Layerbase vs Crunchy Bridge: two ways to buy managed PostgresCrunchy Bridge is Postgres specialists selling instance-hours across AWS, Azure and GCP. Layerbase is a flat monthly price, 18 engines and branching. A head-to-head on pricing, versions, extensions, HA, backups and placement, with worked examples.
- Prisma Postgres alternatives: the plan with neither meterPrisma Postgres bills per operation, Neon bills per CU-hour, and Prisma frames the whole decision as a choice between those two meters. There is a third option: a flat plan with no meter at all. Here are the current Prisma numbers, the arithmetic for a chatty app, where operations pricing genuinely wins, and how to move with the direct TCP string.