Dora NodaRailway spent August 2026 doing something easy to miss and expensive to replicate: it deepened its managed-data layer across the board — automatic Postgres CVE patching, production-grade MySQL and Redis high availability, and full Postgres lifecycle management from the CLI. Here is the honest number for what that bundle buys you out of: a typical web-plus-Postgres-plus-Redis app costs $20-45/month on Railway's meter against a flat $6-12/month on a single Hetzner box running the same three services. The gap — roughly $15-35/month at small scale, doubling once HA enters the picture — is the price of never thinking about patch windows, failover, point-in-time recovery, or connection pooling again.
That is the whole accounting up front: leaving buys you out of real ops work, the price is concrete and recurring, and whether it is worth it depends entirely on how much you value the four jobs below that a self-hosted Postgres container does not do for itself.
| What you are comparing | Railway (metered) | One Hetzner box (flat) |
|---|---|---|
| Web + Postgres + Redis, quiet hobby load | ≈ $12/month | ≈ $6/month (CX22, 2 vCPU / 4 GB) |
| Same stack, typical load with worker | ≈ $25-40/month | ≈ $6-12/month (same box, more utilized) |
| Same stack with HA data layer | ≈ $50-90/month (replicas meter independently) | Second box + ops time (see below) |
| What the extra dollars buy | Patching, failover, PITR, pooling handled | You handle all four (hours, not dollars) |
This post is a pricing-world data point, not a roadmap pitch: managed databases are an explicit bex non-goal. The honest framing is "here is the ops burden leaving buys you out of," priced against owned hardware — not "here is what we will host for you."
What Railway actually shipped
Four items make up the bundle. Each maps to one title claim, and each replaces a specific on-call job.
| Shipped piece | What it does | Replaces |
|---|---|---|
| Postgres automatic CVE patching | Railway rolls Postgres security releases (minor-version patches) for you, no downtime window to plan | Your unattended patch window and version-pin audit |
| MySQL high availability | HA template built on MySQL InnoDB Cluster: primary plus replicas with automatic promotion | Your replica topology and promotion runbook |
| Redis high availability | HA template with colocated Sentinel and an HAProxy entry point | Your Sentinel/failover wiring and client re-pointing |
Postgres management in the CLI (railway postgres) | ha (convert to HA cluster, health, scale nodes, switchover, revert), pitr (archive coverage, restore to a timestamp, volume-backup schedules), pgbouncer (add pooling, tune pool, scale replicas, live utilization) from the terminal with --json for automation | Dashboard round-trips or hand-rolled API scripts for the same three workflows |
Concretely, the CLI now covers the three commands operators actually reach for: railway postgres ha status --service postgres for cluster health, railway postgres pitr restore --service postgres --at 30m for "take me back half an hour" (restores land as a separate service, source untouched), and railway postgres pgbouncer add --service postgres --pool-mode transaction for transaction pooling. HA switchovers still briefly interrupt connections — managed does not mean magic.
(One-line context footnote: Railway also ships a Mongo HA template, private-by-default databases, and volume alerts with self-serve resize. Real features, but outside this post's Postgres/MySQL/Redis scope.)
The through-line is that Railway is selling the absence of four specific pages, not four logos on a template gallery. So price each absence.
What each piece costs to replicate on owned hardware
Nothing here is impossible to self-host — CloudNativePG, MySQL Router, and Sentinel are all solid open source. The cost is attention, on a schedule you do not control.
| Job Railway absorbs | Self-hosted equivalent | Steady-state burden | Failure mode if skipped |
|---|---|---|---|
| Postgres CVE patch windows | Track upstream security releases, test minor-version bump, roll primary and replicas | A few hours per release, 4-8 times a year, on someone else's calendar | CVE-2026-6471 (August 2026, CVSS 7.2): a logical-decoding flaw present since Postgres 9.4 — twelve years — patched across 18.6, 17.11, 16.15, 15.19, and 14.24. Managed fleets patched underneath you; a pinned container image stayed vulnerable until you rebuilt it |
| Postgres HA failover | CloudNativePG or Patroni: streaming-replication primary/standby, health probes, automated promotion (RTO under 30 seconds when tuned) | Days to set up right, then ongoing etcd/consensus care, network-partition handling, and split-brain drills | Primary dies at 3 AM and promotion is manual, untested, or pointed at a stale replica |
| MySQL HA failover | MySQL InnoDB Cluster (Group Replication + Router): multi-node topology with automatic primary election | Same class of work as Postgres HA with a different control plane to learn | Write traffic stalls or splits during a primary loss because the router topology was never chaos-tested |
| Redis HA failover | Sentinel quorum plus an HAProxy or client-side entry point, persistence tuning (RDB + AOF) | Smaller than the SQL cases, but failover still needs a tested quorum — two Sentinels are not a quorum | CVE-2026-25243/25588/25589-class Redis flaws (authenticated RCE and memory corruption, 2026): managed clouds patched silently while self-managed fleets scheduled their own upgrades; meanwhile an untested Sentinel setup promotes nothing |
| Point-in-time recovery + backup verification | wal-g or pgBackRest to object storage, archive-coverage checks, scheduled test restores | The backup job is 20% of the work; proving the restore works — regularly, automatically — is the other 80% | Backups exist, restores do not: the first untested PITR is attempted during the incident it was meant to fix |
| Connection pooling | PgBouncer in transaction mode, pool sizing per service, replica scaling under load | An afternoon to install, ongoing tuning as services multiply | Connection exhaustion under exactly the traffic spike that justified pooling in the first place |
Two patterns worth naming. First, the CVE cases are the same story twice: Postgres and Redis both shipped serious 2026 patches where managed customers were protected by default and self-hosters owned the timeline. Patch latency is the managed-data moat at its most literal — not features, but hours between disclosure and deployment.
Second, every HA row has the same shape: the setup is a weekend, the confidence is a quarterly drill nobody schedules. That is what the meter charges for.
The price math for a typical small app
Railway bills metered consumption against published per-resource rates: about $20 per vCPU per month, $10 per GB of RAM per month, $0.05 per GB of egress, and $0.15 per GB of volume storage per month, with the $5/month Hobby subscription covering the first $5 of usage. Past that credit, your bill is your usage.
RAM dominates at small scale: holding 0.5 GB for a full month is roughly $5 before the app burns a single CPU cycle.
Here is that arithmetic for the shape most real projects run — web service, background worker, Postgres, Redis — at three load levels:
| Tier | Shape | Railway (metered) | Hetzner (flat) |
|---|---|---|---|
| Quiet | Web (0.5 GB), Postgres (0.25 GB, small volume), Redis (0.25 GB), cron inline, ~2 GB egress | ≈ $12/month | CX22 (2 vCPU / 4 GB, ≈ €4.35/month ≈ $5) holds all of it |
| Typical | Web (0.5-1 GB), separate worker, Postgres with real data + volume, Redis, ~10-20 GB egress | ≈ $25-40/month | Same CX22 or a CPX-class box, ≈ $6-12/month flat |
| HA-serious | Above plus HA database topology (replicas meter as independent services) | ≈ $50-90/month and up with data growth | Second box plus the ops table above — dollars stay flat-ish, hours do not |
Sensitivity matters more than any single row. Railway's bill scales with held RAM, average CPU, stored GB, and egress GB independently — double your data or add a replica set and the meter notices immediately. Hetzner's bill does not move at all until you outgrow the box, at which point it moves by exactly one box.
That is why the honest summary is a range, not a number: leaving costs $15-35/month extra at small scale, and the premium widens precisely when the data layer gets serious — which is also when the ops burden it replaces gets serious. Both curves agree on where the pain lives.
The solo-SaaS datapoints floating around 2026 corroborate the middle row: community cost surveys repeatedly land Railway at $5-15/month for a web service plus Postgres at hobby load and $20-45/month once workers, Redis, and real traffic join — against $4-12/month for the equivalent single VPS before management tooling. Different authors, same gap.
Why bex does not chase this (and what to do instead)
Managed Postgres, MySQL, and Redis are a bex non-goal, stated plainly: bex is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own — not a database cloud. Chasing Railway's data layer would mean operating other people's state, with point-in-time recovery guarantees and CVE patch SLAs, on hardware bex does not control. That is a different company.
What to do instead depends on how much of the ops table you want to own:
- Simplest: Postgres beside bex on the same box. For a side project or internal tool, a Postgres container on the same Hetzner machine as your app, with nightly
pgBackRestdumps to object storage and a calendar reminder to test a restore quarterly, covers the quiet tier honestly. Name the gap out loud: no automatic failover, patching is your cron job. - Middle: CloudNativePG on your own cluster. When the app matters enough that manual promotion at 3 AM is unacceptable, run the operator, configure PITR to object storage, and actually drill a failover before you need one. This is the full ops table, accepted deliberately.
- Least ops without leaving the self-hosted app layer: external managed data. Point your bex-hosted app at Neon, Supabase, or any managed Postgres for the state, keep compute on your own machines. You pay a second bill, but it is itemized exactly at the jobs you declined — patching, failover, PITR — which is the entire point of this post's accounting.
Checklist before you pick: is there a tested restore from the last 90 days, is the Postgres image pin tracked against upstream security releases, does failover happen without a human, and does pooling exist before the first traffic spike? Every "no" is a line item Railway's meter would have covered.
When leaving is worth it
Leave — pay the meter — when the team has no one who wants the ops table and the app's revenue or users justify a standing $25-90/month insurance policy against 3 AM pages. Own — pay the flat box plus your own hours — when someone on the team can already run the table, the workload fits on one or two machines, and the premium buys nothing you do not already do on a quiet Tuesday.
Railway's August 2026 bundle did not change that tradeoff. It just itemized it: four concrete jobs, each with a known self-hosted equivalent and a known failure mode, each priced into a meter that starts near your flat box and pulls away exactly as your data layer stops being a container beside the app. Price the absence honestly, pick the side whose costs you prefer — dollars or drills — and stop pretending either side is free.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today. Bring your own Postgres; we will keep the platform honest about what that choice costs.
