Railway's Second Managed HA Database Changes the Migration Math: MySQL HA Goes GA

Five months after Railway shipped one-click HA Postgres, it has ticked the second stateful checkbox: MySQL High Availability went generally available on August 28, 2026. If you are mid-migration and your plan was "self-host Postgres, keep MySQL managed" — or the reverse — the vendor just moved the goalposts, and the honest response is to redo the math rather than assume the old decision still holds.

Here is the short version up front: for a typical small-production pair (one Postgres, one MySQL, each around 2 vCPU / 4 GB RAM / 50 GB), renting both HA checkboxes on Railway runs roughly $350–$525 a month once replica footprints meter, while running both databases on owned Hetzner volumes behind the same Cluster-API fleet costs on the order of $55–$130 in hardware plus stated ops labor. The rest of this post shows the arithmetic, names the three things managed HA still does not answer — backup ownership, failover transparency, egress on replication traffic — and explains why the second checkbox matters more than the first for anyone mid-migration.

Railway ticks its second HA checkbox​

The news arrived in changelog #0305 (August 28, 2026), sharing the headline with a Grok Bot plugin and dashboard favorites. Previously available only through Priority Boarding, MySQL High Availability is now GA for eligible services running a versioned official MySQL 8 or 9 image. The technical shape is respectable: Railway grows your existing service into a single-primary Group Replication cluster, where the database nodes handle membership, replication, and primary election themselves — no separate Sentinel or coordinator tier — and HAProxy instances give applications one stable endpoint routed to whichever node is primary.

Conversion is one click from Database → Config → High Availability. Railway backs up the data, stages replicas and HAProxy instances, and rewrites variable references inside the project. Two honest caveats ship with it: the conversion drops active connections, and hardcoded connection strings still need manual updates.

Context matters here, because this is a trajectory, not an isolated feature. In March 2026 Railway shipped one-click HA Postgres on Patroni — still labeled an experimental add-on in July 2026's independent comparisons. In May 2026, Postgres point-in-time recovery entered Priority Boarding: async WAL archiving to a bucket, restores landing as new services so the source is never overwritten, working on standalone and HA alike.

And on September 4, changelog #0306 brought Postgres management to the terminal — railway postgres ha converts, scales, and fails over clusters; railway postgres pitr manages archive coverage and restores. Postgres gets the deepening operator tooling; MySQL just got its failover story. The pattern is one new stateful commitment per quarter, and migrators should price the platform as a moving target, not a snapshot.

The worked math: two managed HA databases vs. two databases on owned iron​

Comparisons without a defined workload are vibes, so fix a reference workload first: a team running both Postgres (primary app database) and MySQL (a second app or legacy store), each sized small-production at roughly 2 vCPU, 4 GB RAM, and 50 GB of volume storage, with modest cross-service traffic and one region. That is the shape of a team far enough along to care about failover, not a side project.

Wait — the totals look close? That is the labor row doing its job, and it is the most important row in the table. In cash terms the managed pair costs roughly 4–6× the owned hardware; with fully-loaded labor at $125 an hour, the two options land in the same band. At this size you are not buying database capacity, you are buying someone to run the failover. That framing decides everything that follows.

Now the sensitivity, because one point is not an answer. Three variables move the verdict:

• Data size. Railway volumes meter at $0.15/GB-month, so every 100 GB of growth adds $15 per database per month, on every replica that carries it. Owned disks are a step function — you re-tier once, then growth is free until the next step. Past a few hundred GB per database, the metered storage line alone starts to rival the whole owned box.
• Traffic leaving the private surface. Railway egress is a flat $0.05/GB. In-region private replication presumably stays off the meter, but read replicas you expose, cross-region traffic, and heavy API responses all bill per gigabyte. Owned Hetzner bandwidth is bundled by the tens of terabytes — the line item simply does not exist there.
• The N+1 database. This is the one the headline is about. Each additional managed stateful service re-pays the full premium: a third database (Redis HA, Mongo HA — Railway already ships HA templates across all four) adds another metered replica set. On owned iron, the marginal database is nearly free — it lands on the fleet you already run.

The verdict on the math: if your team prices ops labor at market rates and runs exactly two small databases with light traffic, managed HA is defensible — you pay the premium to not carry the pager. The moment any of the three variables grows — data, egress, or database count — the metered total pulls away from the owned total fast, because the premium compounds per service while the owned cost barely moves.

What the HA checkbox still doesn't answer​

"High availability: on" answers exactly one question — what happens when the primary dies. A migration decision needs three more answered, and this is where the fine print lives.

1. Backup ownership. The Postgres side is genuinely maturing: PITR via async WAL archiving to a bucket, restores as new services, CLI-managed archive coverage. But note the shape of that story — your recovery path is a vendor-managed bucket, vendor-managed archive daemon, and vendor-defined restore flow. For MySQL, the GA announcement promises a backup taken at conversion time, and the ongoing story (continuous binlog archiving? point-in-time restores? retention controls?) is thinner in public documentation than Postgres's. On owned iron, the WAL/binlog archives sit on disks and buckets you control, restorable with stock pgBackRest or mysqlbinlog whether or not the platform vendor has a good quarter. Managed backup is convenient until the day you need a backup the vendor's flow never contemplated.

2. Failover transparency. Both engines elect a new primary automatically — Patroni quorum for Postgres, Group Replication election for MySQL, HAProxy rerouting for the latter. What neither gives you is geography: Railway's own blog concedes there are no cross-region replicas and no multi-master — failover is in-region only. If your threat model includes a region going away rather than a node, the HA checkbox does not cover it, on either engine. And every failover still drops connections; the application side (retry with backoff, read-your-write hazards during promotion) is yours to build regardless of who runs the database.

3. Egress on replication traffic. At $0.05/GB flat, egress is the quiet compounder. Today's in-region private replication may be unmetered, but the meter sits on every path your data might take tomorrow — a replica you expose for analytics, a migration dump you pull down, a multi-region future. Owned bandwidth is priced into the box. When comparing, model not just today's traffic but the traffic of your own exit: the team that rents managed state eventually pays egress to leave, levied on the very data gravity the platform spent years building.

None of this is an argument that managed HA is bad — for a team with no database operator, in-region automatic failover plus PITR is enormously better than a single container with a volume. It is an argument that the checkbox is narrower than it looks, and the uncovered parts are exactly the parts that get expensive later.

Why the second checkbox matters more than the first​

Here is the strategic point the TODO-sized version of this story buries: the first managed stateful service is a convenience, but the second one is a commitment. Each HA database you rent deepens platform coupling along three axes at once — operational (your runbooks assume their dashboard, their CLI, their restore flow), financial (another metered replica set compounding per gigabyte), and logistical (your backups, your failover testing, and your eventual exit all route through one vendor's surfaces).

Concretely: the team that told itself "we'll self-host Postgres but keep MySQL managed" just watched the managed side of that split get strictly better — GA failover, one-click conversion, variable rewiring. That feels like a gift, and operationally it is. But it also raises the cost of ever unifying on owned iron, because now both databases would need a migration instead of one, and the managed one's backup/HA story is the one your team practices least. Every HA checkbox the vendor ticks makes the split harder to justify and harder to unwind — simultaneously.

So here is a decision framework for teams mid-migration, stated as plainly as possible:

• Stay managed on both if you have no one who will carry the database pager, your data is under ~100 GB per engine, traffic stays in-region and private, and you can name the quarter you will revisit the decision. Set a calendar reminder, not just a checkbox.
• Move both to owned iron if you already run a fleet (the marginal database is nearly free), data or egress is growing, you need backup flows the vendor does not offer, or database number three is on the horizon. The second migration is cheaper done alongside the first than alone a year later.
• Keep the split only as a timed bridge with a written expiry — never as a steady state. A permanent split pays the managed premium forever while keeping the self-hosting skills (and pager) anyway. That is the worst of both, whatever the changelog says.

The meta-lesson: evaluate a PaaS's stateful roadmap as a subscription to future coupling, not a list of features. Railway is shipping roughly one stateful commitment per quarter — HA Postgres, PITR, MySQL HA, CLI operator tooling — and each one is genuinely good. The question was never whether the features are good. It is whether your migration plan survives them all being good at once.

The bottom line​

Railway's MySQL HA hitting GA five months after HA Postgres tells you where the puck is going: managed stateful services are becoming table stakes for PaaS vendors, and each one makes "just keep the database managed" a little more tempting and a little more expensive. Run the worked math for your data size, your egress, and your database count — not the vendor's reference sizing — and answer the three uncovered questions (who owns the backups, what failover actually covers, what the data's exit costs) before the checkbox answers them for you.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with Postgres and MySQL running on your own volumes behind the same fleet instead of rented per-checkbox. Star the repo on GitHub or deploy your first app today.