Betting on Percona

The decision (USER, 2026-10-20, verbatim framing): deprecate all MariaDB server/cluster for new projects and focus on the Percona offering for both MySQL (Percona Server for MySQL, PXC) and PostgreSQL (Percona Distribution for PostgreSQL / Patroni) — using only Percona distributions for databases. Even taking into consideration that MariaDB is the default on Debian servers.

The grounding source: Marco Tusa, “The Galera Crossroads — Why PXC is the lifeline for MariaDB Community users” (32 KB, captured; USER: “That post only confirms and grounds my decision.”)

What the post establishes (the facts behind the bet)

• Codership is gone — the original Galera company is dead.
• MariaDB plc moves active Galera development strictly to its Enterprise offering.
• MariaDB Foundation (board minutes 2026-02-25, “Option 2”) keeps the Galera/wsrep code in the community server as-is — future evolution depends entirely on outside community contributions. Community Galera is frozen, not maintained.
• PXC is not a rebadge: Percona tracks the upstream Galera fork and “adds many critical fixes that make it actually work in some places (IST stability, gcache, NBO)”. PXC and MariaDB Galera Cluster are NOT binary-compatible — data dictionary/system tables, GTID format, InnoDB/XtraDB divergence, binlog enforcement, wsrep patch divergence, JSON/SQL-modes/reserved-words all differ. Migration is a rebuild-and-replicate, not a binary swap.
• The post’s detailed internals (write-set replication flow, brute-force abort, flow control + observability, FC tuning variables side-by-side) are the PXC-vs-MariaDB operator reference.

Why the bet makes sense (the consolidating logic)

1. One vendor, both engines: Percona distributes MySQL-compatible (PS for MySQL, PXC for sync multi-master) and PostgreSQL (Percona Distribution for PostgreSQL with Patroni for HA) — one packaging, one tooling (PMM for monitoring — already the lesson-63 lane of the jsystems course), one support ecosystem. MariaDB offers neither a credible community Galera future nor a Postgres lane.
2. Debian default ≠ production choice: the distro default is a packaging convenience, not a lifecycle commitment — the same class of decision as not using distro Redis/Python.
3. Vendor trajectory: MariaDB plc’s enterprise-fork move repeats the pattern this vault tracks elsewhere (open-core squeeze: community frozen, paid lane evolves). Percona’s model is support/services around fully-open distributions — the incentives point the right way for a community user.
4. Convergence with existing lanes: High Availability and the jsystems PG course (Patroni, PMM) already point at Percona tooling; MangaDex runs Percona MySQL in production as the captured field example.

The full portfolio (USER correction, 2026-10-20)

Percona covers more than MySQL/PG: Percona Server for MongoDB (drop-in for Community, SSPL-free, adds hot backups/audit/PAM) with the Distribution for MongoDB bundling PBM; and Valkey via Percona Packages for Valkey (2024+ — packages + support, not a full “Distribution” brand; the smallest delta of the five lanes). So the bet covers: MySQL (PS + PXC), PostgreSQL (+ Patroni), MongoDB, Valkey.

The follow-up work (USER ask, 2026-10-20)

1. Research: upstream vs Debian vs Percona binaries/configs — done as ansible-cot/docs/percona-vs-upstream-vs-debian.md (repo-local, gates the roles): Debian’s default-mysql-server is MariaDB (the trap); Percona PS = drop-in + backup-lock/instrumentation/plugins; Percona PG = PG + Patroni + pgBackRest/WAL-G bundled; PSMDB = Community-parity + hot backup/audit; Valkey = smallest delta. Per-lane repo/package deltas + open questions for impl-time verification.
2. Create Ansible roles for Percona distributions (ansible-cot repo): role map set — dedupe the two existing PXC roles; new ps_percona_mysql (standalone, simplest starter); retarget ps_postgresql PGDG→Percona repo; new ps_patroni; retarget ps_mongodb Community→PSMDB; rename ps_redis→ps_valkey (low prio); shared percona_repo substrate role. Implementation follows the research doc — status tracked there.

Migration posture (implied, to plan when triggered)

• New projects: Percona distributions only — PS for MySQL where single-node, PXC where sync multi-master, Percona PG + Patroni where Postgres.
• Existing MariaDB: no forced migration (as-is still works), but no new deployments; PXC migration = logical rebuild (dump/replicate), never binary swap.
• Watch: Percona’s own roadmap health (a vendor bet is still a vendor bet — revisit if Percona ever repeats MariaDB plc’s move).

Kin

• High Availability — the Patroni/PXC lane this decision standardizes on
• PostgreSQL anti-patterns — the engine-side discipline for the PG half
• MangaDex engineering — Percona MySQL in production at 2k req/s on a shoestring
• jsystems Kurs administracji PostgreSQL (lessons 50 Patroni, 63 PMM) — the hands-on lane