What changed
Railway announced on August 28, 2026 that MySQL High Availability is generally available for eligible services using versioned official MySQL 8 or 9 images. Railway converts an existing standalone MySQL service into a single-primary Group Replication cluster, adds an even number of replicas so the total database-node count remains odd, and places HAProxy in front of the cluster as the stable connection endpoint. If the primary becomes unreachable, the remaining MySQL members elect a replacement and HAProxy begins routing new connections to it. Railway’s conversion workflow takes a backup, stages the replicas and proxy services, and rewrites variable references inside the project. The feature had previously been limited to Priority Boarding.
Why it matters
For smaller teams using Railway as an application platform, database failover previously required a separate architecture or accepting one MySQL service as a single point of failure. The GA path makes high availability an in-platform conversion rather than a database migration to another vendor. That can materially reduce operational work, but it does not make failure invisible: connections to the old primary drop during failover, clients still need reconnect logic, and the extra database and HAProxy services add resource cost and more components to monitor.
High availability is now a conversion of the existing service
An eligible MySQL service exposes a High Availability control in Railway. During conversion Railway backs up the database, provisions replicas plus HAProxy as staged changes and adopts the original data volume into the cluster. Variable references such as `MYSQL_URL` inside the same Railway project are migrated automatically to the new HAProxy service.
MySQL itself performs membership and primary election
Railway uses MySQL Group Replication in single-primary mode rather than a separate consensus coordinator. Customers can add 2, 4, 6 or 8 replicas to the original primary, producing clusters of 3, 5, 7 or 9 data nodes so a majority can be established during failures or partitions. Secondary nodes stay `super_read_only`.
HAProxy gives applications one endpoint across failovers
Clients connect through HAProxy rather than directly to a database node. When the current primary fails, Group Replication elects a new primary and HAProxy reroutes connections after its next role probe. Existing connections to the failed node are lost, so applications still need normal database reconnect/retry behavior.
The replicas are not a read-scaling tier
Railway’s current design sends all reads and writes to the primary through HAProxy. The replicas exist to preserve quorum and take over during failure; there is no separate read endpoint over secondaries. Teams that need read scaling should not assume enabling HA solves that requirement.
Eligibility is deliberately narrow
Railway supports official MySQL images with versioned MySQL 8 or 9 tags. `latest`, MariaDB, Percona and other variants are not eligible. A custom start command also blocks conversion until it is reset, because Railway’s cluster wrapper manages startup and replication configuration.
Conversion and cost still need planning
The conversion drops active connections and changes endpoints. Railway automatically rewrites project variable references, but literal connection strings in code, other Railway projects, CI systems or external tools must be updated manually. Railway bills CPU, memory, storage and egress by resource use, so multiple MySQL nodes and HAProxy services also increase the infrastructure footprint.
The launch announcement and documentation are briefly out of sync
Railway’s August 28 changelog explicitly says MySQL HA is now generally available for eligible services. The detailed documentation page still contains older Priority Boarding/beta wording in parts of the page. Builders should use the current product/changelog status for availability while validating their own dashboard eligibility before planning a production conversion.