Postgres vs MySQL in Production: Replication, Backups, Pooling, and HA (2026)

Every section includes honest “this is genuinely harder on this side” annotations. No hand-waving.

Replication

Postgres

Streaming (physical) replication. Logical replication (PG 10+, mature by 16-17). Logical replication failover (PG 17). Failover via Patroni, Stolon, repmgr.

MySQL

Binlog replication (statement / row / mixed) — the most battle-tested replication system in production. Group Replication (5.7+). InnoDB Cluster (built on Group Replication).

Genuinely harder: MySQL | MySQL Group Replication has documented consistency issues under network partition (Jepsen 2023). Binlog replication is extremely mature. Postgres logical replication is now production-grade but Patroni setup has a learning curve.

Source: jepsen.io/analyses (MySQL Group Replication)

Backup tooling

Postgres

pg_basebackup (physical), pg_dump / pg_dumpall (logical), pgBackRest (continuous archiving), WAL-G, Barman.

MySQL

mysqldump (logical), Percona XtraBackup (physical, hot backup), MySQL Enterprise Backup (Oracle-proprietary).

Genuinely harder: MySQL (open tooling) | The open-source MySQL backup story leans on Percona's tooling (XtraBackup). Oracle's Enterprise Backup is proprietary. Postgres has a stronger open-source backup ecosystem (pgBackRest, WAL-G, Barman are all community-driven).

Source: percona.com/software/mysql-database/percona-xtrabackup

Point-in-time recovery (PITR)

Postgres

WAL-based PITR: restore to any LSN or timestamp. Tools: pgBackRest, WAL-G, Barman.

MySQL

Binlog-based PITR: restore by binlog position or GTID. Combination of physical backup + binlog replay.

Genuinely harder: Neither significantly | Both support PITR in production. Postgres WAL-based PITR is conceptually simpler. MySQL GTID-based PITR is mature and widely deployed.

Connection pooling

Postgres

Forks a new OS process per connection by default (expensive at scale). PgBouncer is near-universal in production. Modes: session / transaction / statement — each with tradeoffs (prepared statements, LISTEN/NOTIFY break in transaction mode).

MySQL

Thread-pool plugin (community + Enterprise editions). ProxySQL (open-source). Per-connection cost is lower than Postgres by default.

Genuinely harder: Postgres | PgBouncer is universal in production because Postgres's default connection scaling is expensive. This is the most common Postgres operational pain. PgBouncer transaction mode breaks prepared statements and LISTEN/NOTIFY — require session mode or application changes.

Source: pgbouncer.org

High availability

Postgres

Patroni + etcd (canonical HA solution). pg_auto_failover. repmgr. Cloud: RDS Multi-AZ, Aurora Postgres, Cloud SQL HA.

MySQL

InnoDB Cluster + MySQL Router (Oracle). MHA (MySQL Master HA, older). Vitess (sharded HA). Cloud: RDS Multi-AZ, Aurora MySQL, Cloud SQL HA.

Genuinely harder: Neither significantly | Both have multiple production-grade HA options. Patroni has become the de facto Postgres HA standard. MySQL's InnoDB Cluster is Oracle's official path.

Sharding: Vitess vs Citus

Postgres

Citus (Microsoft-supported, open-source). Strong HTAP and analytics. Younger track record than Vitess.

MySQL

Vitess (YouTube origin, Linux Foundation). Strong sharded OLTP. YouTube, Slack, GitHub, Booking.com battle-tested.

Genuinely harder: Citus (less mature) | Vitess has ~15 years of production at YouTube scale. Citus is younger but well-maintained by Microsoft post-acquisition. For pure sharded OLTP, Vitess has the deeper production trail.

Source: vitess.io

Operational pain summary

Pain area	Postgres	MySQL
Connection scaling	PgBouncer needed at scale; setup and mode tradeoffs	Less acute; thread-pool available
VACUUM / autovacuum tuning	Real ongoing tuning at high update workloads	Not applicable (no MVCC bloat)
Replication consistency under partition	Strong (streaming replication is synchronous option)	Group Replication had issues (Jepsen 2023)
Open backup tooling	pgBackRest, WAL-G, Barman — all open	XtraBackup (Percona) is the open option; Enterprise Backup is proprietary
Stored procedure ecosystem	Multi-language: PL/pgSQL, PL/Python, PL/V8, PL/Perl	SQL only; no embedded scripting languages
Online DDL	CONCURRENTLY for index creation; some heavy ops need pg_repack	Online DDL with documented limits by operation type
Replication setup learning curve	Patroni + etcd is not trivial; improving in managed options	Binlog replication is extremely well-trodden

Amber cells indicate the harder side per area.

Platform engineering cost (DBA teams, on-call, tooling): platformengineeringcost.com | Hiring DBAs for each: engineeringhiringcost.com