How to Choose a Kubernetes Database Operator for MySQL and PostgreSQL

How to Choose a Kubernetes Database Operator for MySQL and PostgreSQL

Running a database on Kubernetes used to mean bolting a StatefulSet onto a Deployment manifest and hoping for the best.


That approach still starts most journeys, but it stalls quickly once a team needs automated failover, scheduled backups, or safe version upgrades.


A Kubernetes database operator fills that gap by encoding the operational knowledge of a database administrator into a controller that watches your cluster and reacts to it.


The problem is not a shortage of operators. It is picking the right one for MySQL or PostgreSQL without discovering its limitations during an incident. This article lays out a practical framework for that decision.


What a Database Operator Actually Owns


A plain StatefulSet gives you stable pod identity and one persistent volume per replica. That is useful, but it says nothing about which pod is primary, how replication is configured, or what happens when a node fails.


A database operator extends the Kubernetes API with custom resources, then continuously reconciles the live cluster state against the desired state you declare.


In practice, a mature operator for MySQL or PostgreSQL should own:


  1. Cluster bootstrapping, including initial replication setup
  2. Automated failover and primary promotion
  3. Scheduled full and incremental backups with point in time recovery
  4. Rolling minor and major version upgrades
  5. Connection routing through a proxy layer such as ProxySQL, PgBouncer, or HAProxy
  6. Metrics exposure for Prometheus and integration with existing observability stacks

If an option only handles the first two items on that list, treat it as infrastructure automation rather than a production ready operator.


Comparing the Major Options


For PostgreSQL, three operators dominate real deployments: CloudNativePG, the Crunchy Postgres Operator, and the Zalando Postgres Operator built on Patroni. CloudNativePG manages persistent volume claims directly rather than relying on a StatefulSet, which removes a layer of indirection during failover.


The Zalando operator has a longer production track record and leans on Patroni for consensus based leader election, which some teams already trust from non Kubernetes deployments.


Operator

Failover mechanism

Backup approach

Best fit

CloudNativePG

Native controller, no Patroni dependency

Continuous WAL archiving to object storage

New PostgreSQL deployments wanting fewer moving parts

Zalando Postgres Operator

Patroni with distributed consensus

WAL-E or WAL-G to S3 compatible storage

Teams with existing Patroni expertise

Crunchy Postgres Operator

Patroni based

pgBackRest

Regulated environments needing vendor support


For MySQL, the Percona Operator for MySQL and the Percona Operator based on Percona XtraDB Cluster cover most needs, alongside Oracle's own MySQL Operator for Kubernetes.


Percona's options are fully open source and support MySQL, PostgreSQL, and MongoDB with a consistent automation model, which matters if your platform team standardizes tooling across database engines rather than picking one operator per workload.


Read: Inside the Architecture of a Gojek Clone App System


A Selection Framework


Rather than choosing based on GitHub star counts, evaluate candidates against four questions:


  1. What is the measured recovery time during a primary failure? Run a controlled failover in a staging cluster and record promotion time, client reconnect behavior, and any transactions lost. Do not accept a vendor's stated numbers without testing against your own storage class and network conditions.
  2. How does the operator handle version upgrades? Some operators automate upgrades with pre-flight checks and automatic rollback. Others require manual intervention for every minor release, which becomes a bottleneck as your fleet grows.
  3. Does backup and restore actually work end to end? A backup job that completes successfully is not the same as a backup that restores into a working cluster. Schedule a monthly restore drill against a fresh namespace and confirm the application can reconnect.
  4. What operational visibility does it expose? Look for built-in Prometheus metrics covering replication lag, connection pool saturation, and storage headroom, since these are the signals that predict an incident before it happens.

Production Readiness Beyond the Operator


Choosing an operator solves cluster lifecycle management, but daily database consultant does not disappear.


Review replication lag and WAL or binlog retention regularly, watch persistent volume claim capacity before it becomes an outage, and keep a documented runbook for the failure modes you tested during evaluation.


Teams that treat the operator as the entire solution, rather than one layer in a broader operational practice, tend to relearn these lessons during an actual outage.


Mydbops works with engineering teams evaluating and running MySQL and PostgreSQL operators on Kubernetes, turning that evaluation into a repeatable checklist rather than a one time decision made under deadline pressure.


Whichever operator you choose, the goal stays the same: predictable behavior under failure, verified through testing rather than assumed from documentation.


Key Takeaways


  1. A database operator should own failover, backups, upgrades, and connection routing, not just pod scheduling
  2. CloudNativePG and Percona operators currently lead their respective ecosystems for new deployments
  3. Test failover and restore procedures directly rather than trusting documented recovery times
  4. Operational discipline around monitoring and runbooks remains necessary even with a mature operator in place