MariaDB vs MySQL vs PostgreSQL: choosing an open-source database

"Which database should we use?" is the wrong question. The right one is: what does this workload look like, what does your team already know, and what does your existing stack assume? Get those answers and the database usually picks itself. We run and support all three, so here is how we think it through — without pretending there is one winner.

MySQL and MariaDB are not the same thing anymore

This trips people up, so it comes first. MariaDB began in 2009 as a fork of MySQL, started by MySQL's original author in response to Oracle's then-pending acquisition of Sun — and with it MySQL — and for a while it was a genuine drop-in replacement. For many simpler applications it still is, sharing the wire protocol and broadly the same SQL. But that equivalence no longer holds in general. Over more than a decade the two have diverged in features, in some SQL syntax, and in how they implement things like JSON, GTID-based replication (the two use incompatible GTID formats), authentication, and — in MariaDB — system-versioned (temporal) tables and the Aria and analytical ColumnStore engines. MySQL 8, run by Oracle, has its own additions the other lacks.

The wire protocol and the basics still rhyme, and many applications run on both. But at MySQL 8 and MariaDB 10.x/11.x, treat them as two closely related but independently evolving databases — enough in common that plenty of apps run on either, enough divergence that you cannot assume identical behaviour. A migration in either direction is a compatibility project, not a rename. A migration in either direction needs testing, and increasingly the client drivers and connectors distinguish between them. Choosing "MySQL or MariaDB" is a real decision, not a branding one.

What each is genuinely good at

PostgreSQL is the database you choose when correctness and capability matter. It has arguably the richest type system of the three — binary JSONB (MySQL and MariaDB have a JSON type too, but PostgreSQL indexes and queries it more powerfully), arrays, ranges, and fully custom types — genuinely powerful indexing (GIN, GiST, BRIN alongside B-tree), transactional DDL so most schema changes roll back cleanly inside a transaction, and an extension ecosystem that is its real superpower: PostGIS for geospatial, pg_stat_statements for query analysis, and pgvector — now a mainstream extension — for embeddings and AI workloads. It is strict about standards and data integrity by default. The cost is operational: its MVCC design needs autovacuum understood and tuned, and it rewards an operator who knows it.

MySQL earns its place through ubiquity and simplicity. For read-heavy, straightforward web workloads it is fast, well-understood, and everywhere — a vast amount of the web (WordPress and most PHP applications) assumes it. If your framework, ORM, or off-the-shelf application expects MySQL, that expectation is a good enough reason on its own.

MariaDB is the community-governed open alternative to Oracle's MySQL. It stays close to MySQL's use cases while adding its own: Galera — virtually synchronous, certification-based multi-primary clustering — is bundled and integrated (its replication hooks have shipped in MariaDB Server for years), and it ships engines MySQL does not. Organisations often choose it specifically to stay on a fully open, non-Oracle path while keeping the familiar MySQL-shaped workflow.

How to actually decide

Two honest caveats. First, all three are excellent and none of these is a mistake — the failure mode is not "picked the wrong engine," it is running any of them badly. Second, the switching cost is real: migrating between engines means rewriting engine-specific SQL, retesting the ORM layer, and re-doing replication and backups. Pick deliberately, because you will live with it.

The part that actually matters: operations

Whichever you choose, production reliability comes from the operational layer, not the badge:

• •Replication and HA. PostgreSQL uses streaming and logical replication, typically fronted by Patroni for automated failover. MySQL and MariaDB offer asynchronous and semi-synchronous replication, with Galera giving MariaDB virtually-synchronous multi-primary. Each has different failure modes you have to design for.
• •Backups you have actually restored. A backup you have never test-restored is a hope, not a backup. This is engine-independent and non-negotiable.
• •Connection pooling. PostgreSQL uses a process per connection, so a pooler like PgBouncer becomes effectively mandatory as connection counts climb. MySQL and MariaDB use lighter per-connection threads and tolerate far more open connections natively — there ProxySQL earns its keep through query routing, read/write splitting and multiplexing at scale rather than sheer connection survival.
• •Monitoring the right signals. Replication lag, slow queries, buffer/cache hit ratios, and — for PostgreSQL specifically — autovacuum health and transaction-ID wraparound.

What we do

We design, migrate, run, and tune all three — see our database services. In practice we default to PostgreSQL for new and complex systems, and we run MySQL or MariaDB wherever the application ecosystem calls for it, which is often. The engine is a starting point; what keeps a database up at 3am is replication that fails over cleanly, backups that have been restored, and monitoring that catches the problem before your users do. That is the part we are actually paid for.