Multi-Region Database Packages Compared: Which One Survives a Data Centre, and What Each Costs You in Latency

Once an application must survive the loss of a data centre, the database is the hard part, and the marketplace offers four different answers to it. They are not four flavours of the same thing: they differ in whether every region can write, how stale a remote copy can be, and what a commit costs in milliseconds. This post follows a solutions architect comparing them for one application on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.

The application is an order-management system for a wholesaler we will call Halvard Trading, with warehouses in the UK and Germany and a growing US customer base. The candidates are the MySQL/MariaDB/Percona Multi-Region Cluster, the MariaDB Multi-Region Galera Cluster, the PostgreSQL Multi-Region Cluster and, for the cache, the Multi-Region Redis Cluster.

The one question that sorts them

Every multi-region database trades between two things: how quickly a write is visible everywhere, and how much a write costs in latency. Asynchronous replication commits locally and propagates afterwards, so writes are fast and remote copies lag by roughly the network round trip. Synchronous replication waits for every region before commit returns, so copies are identical the moment a write completes and every commit pays the round trip to the farthest region. The platform's own guidance for the WordPress multi-region packages puts a number on the boundary: below about 20 milliseconds between all regions, synchronous is viable; above it, asynchronous is the better fit. MassiveGRID's four regions (New York, London, Frankfurt, Singapore) span 15 to 200 milliseconds, so the answer depends on which ones you pick.

The four packages, side by side

MySQL/MariaDB/Percona: the pragmatic default

The asynchronous MySQL family package is the one most applications should start with. It deploys database nodes in every selected region, joined by GTID-based replication, with a ProxySQL entry point in each region that sends reads to local nodes and writes to the primary. The primary-primary topology means a second region holds a primary that can start accepting writes if the first is lost; further regions hold replicas. Writes are not slowed by distance, because replication is asynchronous, and the platform documentation recommends a primary-primary-secondary layout on three regions. What you accept is a lag: a row written in London is readable in New York a few tens of milliseconds later, and a failover during that window can lose the writes still in flight. For Halvard's order system, which writes orders in Europe and reads them everywhere, that is the natural fit.

Galera: when every region must write, and the map allows it

The Galera package is a single synchronous cluster whose nodes are grouped into a segment per region, and every node accepts writes. Nothing is ever stale and no committed transaction can be lost to a region failure, provided a majority of nodes remains, which is why it needs at least three regions. The price is paid on every commit: the round trip to the farthest segment. London plus Frankfurt plus a third European-adjacent region keeps that near the 20 millisecond line; adding New York makes it about 80; Singapore rules it out. The architect's rule of thumb is that Galera is the choice when two conditions hold together: writes must be accepted in more than one region, and the regions are close. Halvard's US customers make the second condition fail, so Galera is not chosen, and this blog's dedicated Galera post walks through the arithmetic in detail.

PostgreSQL: one primary, standbys where the readers are

For PostgreSQL there is one topology: a primary in the first region and hot standbys in the others, kept current by streaming replication, with a highly available Pgpool-II layer per region that balances reads locally and monitors the cluster. Failover to another region is a promotion, which the architect prefers to keep as a deliberate step across regions to avoid two primaries during a partition. If Halvard's system had been on PostgreSQL, this is where it would go; the trade-offs match the MySQL package's, with PostgreSQL's replication semantics.

Redis: the cache needs its own answer

Halvard's application caches product data and sessions in Redis, and a cache in one region is a slow cache everywhere else. The Redis package offers two topologies across three or more regions: Maximum Performance, sharding the key space across regions with replicas so each region serves local reads and the cluster scales; or Maximum Reliability, primaries in one region and replicas in the others, which survives losing one or two regions at the cost of scalability. Replication is asynchronous either way. The architect picks performance, with hash tags pinning each tenant's keys to their home region's primary so writes are local too.

The decision, and what it costs

Halvard runs the asynchronous MySQL package across London (primary), Frankfurt (second primary) and New York (replica), with the Redis package in performance topology across the same three, and the application writes through the local ProxySQL, which forwards to London. Losing Frankfurt or New York changes nothing for writes; losing London promotes Frankfurt per the topology's design. Nine database and proxy nodes and nine Redis nodes, all scaling by the hour in cloudlets (128 MiB of RAM plus 400 MHz of CPU), average about 130 cloudlets an hour, roughly $315 a month before discounts at MassiveGRID's published $0.003372 per cloudlet-hour, plus inter-region traffic. The architect's summary for the board: the database survives a data centre, reads are local on both sides of the Atlantic, and the only thing that crosses the ocean is a write, once.

Frequently Asked Questions

Can I mix these, for example MySQL async for the main database and Galera for a small shared table?

Yes. Each package is its own set of environments in one environment group, and an application can connect to several. Keep each database's topology matched to its own write pattern rather than forcing one model on everything.

Do the multi-region packages work with the backup and TLS add-ons?

Yes. The Database Backup/Restore add-on supports the multi-region variants and prefers a replica; the MySQL, PostgreSQL and Redis TLS add-ons install on the multi-region layers, and the PostgreSQL add-on can encrypt replication between regions.

How do I decide between two and three regions?

Galera and Redis require at least three. The asynchronous MySQL package works with two, but a third region with a replica gives you a copy that survives the loss of either primary region and is the documented recommendation. PostgreSQL's package is primary plus two standbys by design.