From MariaDB Galera to CloudNativePG

I ran a three-node MariaDB Galera cluster for high availability. It worked well. I migrated the whole thing to PostgreSQL on CloudNativePG anyway. Here's the reasoning, and the trade I knowingly made.

What Galera gave me

Synchronous replication, automatic failover with quorum, zero data loss on a single node failure, all operator-managed. For a MySQL-flavoured workload it's genuinely solid HA, and I have no complaints about how it behaved.

Why move at all

Two reasons. I wanted Postgres on the application side — richer types, proper JSON, and an ecosystem I prefer. And I did not want to run two database engines in the same cluster. Consolidating onto one engine with a strong Kubernetes operator meant one backup story, one HA model, and one thing to learn deeply rather than two things learned shallowly.

The migration

Environment by environment — development first, then staging, then production. For each: stand up CloudNativePG alongside the existing database, migrate schema and data, repoint the app (pdo_mysql becomes pdo_pgsql), validate, and only then remove MariaDB. GitOps made every cutover an auditable pull request I could reason about and roll back.

What CloudNativePG does well

Operator-managed primary and replicas, automated failover, scheduled backups, and — as I found out the hard way in a later disk-full incident — conservative safety phases that refuse to start an instance into a broken state rather than risk corruption. The thing that made an outage longer also made it impossible to lose data.

The honest trade

My CloudNativePG setup runs asynchronous replication, so there's a theoretical few-seconds data-loss window if the primary hard-crashes, in exchange for lower write latency. Galera's synchronous replication didn't have that window. For my workload async is the right call — but it is a real trade, and you should know which one you've chosen rather than discovering it during an incident.