PostgreSQL vs MariaDB
MariaDB is a MySQL fork that has deeply diverged — governance, 2026 version status, native VECTOR type, storage engines, and how to choose among MySQL, MariaDB, and PostgreSQL
MariaDB began in 2009 as a fork of MySQL by MySQL's original developers around Oracle's acquisition of Sun, but it is no longer a drop-in replacement: since the 10.x series it has diverged into its own database with its own features, release model, and incompatibilities. Against PostgreSQL the interesting contrast is that both are community-governed open-source projects — yet they differ sharply in SQL strictness, extensibility, and architecture.
Checked against official sources, 2026-08
Version and support statements on this page follow the official lifecycle pages as of August 2026: MariaDB on endoflife.date, mariadb.org, the MariaDB vector documentation, and the PostgreSQL versioning policy. Verify version-specific details before relying on them.
Governance and licensing
| PostgreSQL | MariaDB | |
|---|---|---|
| Steward | PostgreSQL Global Development Group, a distributed community | MariaDB Foundation, a non-profit that guarantees the code stays open; MariaDB plc is the primary code contributor and sells enterprise offerings around it |
| License | PostgreSQL License — permissive, BSD-like | GPLv2; the Foundation states the server "will remain Free and Open Source Software licensed under GPLv2, independent of any commercial entities" |
| Fork history | N/A (own lineage since the 1980s POSTGRES project) | Forked from MySQL in 2009; 5.1–5.5 tracked MySQL closely, from 10.0 onward the numbering and features went their own way |
The Foundation/Corporation split is a middle position between PostgreSQL's pure community model and MySQL's single-vendor ownership: governance is safeguarded by a foundation, but most engineering still comes from one company.
Version landscape in 2026
MariaDB (per endoflife.date/mariadb):
| Release | Status as of August 2026 |
|---|---|
| 10.6 LTS | Community support ended July 2026 (enterprise support continues) |
| 10.11 LTS | Community support to February 2028 |
| 11.4 LTS | Community support to May 2029 — the last line under the old 5-year community policy |
| 11.8 LTS | Community support to June 2028 under the current 3-year policy |
| 12.0–12.2 | Rolling releases, each supported only until the next one ships |
| 12.3 LTS | Released May 2026; first LTS under the new model where each major's .3 release is the LTS |
Rolling releases arrive quarterly and expire when the next ships; LTS releases arrive about yearly with three years of community support (five years up to 11.4). One notable capability milestone: a native VECTOR data type with vector indexes landed in 11.7.1 and is GA in the 11.8 LTS.
PostgreSQL for the same moment (per the versioning policy): 14 is supported until November 2026, 15 through 18 until November 2027–2030 respectively, and 19 is in beta (Beta 2), not for production. One major per year, five years of support each.
Capability differences vs PostgreSQL
| PostgreSQL | MariaDB | |
|---|---|---|
| Wire protocol | PostgreSQL's own protocol (pgwire) | Speaks the MySQL client/server protocol — MySQL drivers, connectors, proxies, and most tooling work unchanged |
| Transactions and isolation | Default READ COMMITTED; MVCC-based REPEATABLE READ and SERIALIZABLE (SSI) | InnoDB: default REPEATABLE READ with next-key locks |
| Transactional DDL | Most DDL rolls back with the transaction | DDL causes an implicit commit, as in MySQL |
| JSON | jsonb binary storage, rich operators, GIN indexing | JSON is an alias for LONGTEXT with a JSON_VALID check — text storage, no binary JSON type |
| Vector search | Via the pgvector extension | Native VECTOR(N) type and vector index since 11.7.1, GA in 11.8 LTS |
| Sequences | Sequences are core; identity columns since 10 | SEQUENCE objects since 10.3 (MySQL does not have them) |
| CTEs and window functions | Long-standing (since 8.4, 2009) | Since 10.2 (2017) |
| Storage engines | Single engine with pluggable index access methods; table access methods since 12 | Pluggable engines: InnoDB (default), Aria, MyISAM, plus specialized ones — Spider for sharding across servers, ColumnStore for columnar analytics (the MariaDB Analytics line), MyRocks |
| Replication | Built-in physical streaming; built-in logical since 10 | Binlog-based replication; Galera Cluster for synchronous multi-primary |
| Extension ecosystem | In-server extensions adding types, operators, index methods (PostGIS, pgvector, TimescaleDB) | Plugin API centered on storage engines; no comparable mechanism for types or index methods |
MariaDB's distinguishing cards are the MySQL-protocol ecosystem it plugs into, the native vector type, and the storage-engine model that lets sharding (Spider) or columnar analytics (ColumnStore) live inside the same server. PostgreSQL's are stricter semantics, transactional DDL, and an extension ecosystem that changes what the database is, not just how it stores.
The behavioral traps of the MySQL lineage — implicit type conversion, sql_mode-dependent leniency, collation-driven case-insensitive comparison, AUTO_INCREMENT vs identity — apply to MariaDB as well; they are catalogued in PostgreSQL vs MySQL. MariaDB has supported sequences and had ONLY_FULL_GROUP_BY on by default since 10.2, so it sits slightly closer to PostgreSQL on those two points than MySQL does.
Choosing among MySQL, MariaDB, and PostgreSQL
The three-way decision usually decomposes like this:
- The application dictates the MySQL protocol (WordPress, LAMP-era PHP, hosting control panels, MySQL-certified commercial software) → the real choice is MariaDB vs MySQL, and PostgreSQL vs MySQL covers that axis. Within it, MariaDB is the pick when GPL-only licensing, foundation governance, sequences, the native VECTOR type, or the extra storage engines matter, and when exact MySQL 8.0 compatibility is not a requirement — the two have diverged enough that MariaDB is no longer a drop-in replacement for MySQL 8.0. MySQL is the pick when an Oracle support contract, InnoDB Cluster tooling, or vendor certification is a hard requirement.
- A new application with no MySQL-ecosystem constraint → PostgreSQL is the usual default: stricter semantics, transactional DDL, and the extension ecosystem (extensions ecosystem).
- Team experience and hosting availability are legitimate inputs in both directions — a team that operates MariaDB well runs it more safely than a database it doesn't know, and many hosting platforms offer only MySQL/MariaDB.
What is rarely a good reason: a benchmark. All three handle ordinary OLTP workloads well; the decision is about semantics, ecosystem, and operations.
Migration pointers
MariaDB to PostgreSQL is the same class of migration as MySQL to PostgreSQL: pgloader moves schema and data, and the work is in the behavior differences (type coercion, case sensitivity, AUTO_INCREMENT). MariaDB-specific items to check are its text-based JSON columns and any use of Spider/ColumnStore tables, which have no direct PostgreSQL equivalent. Note also that MariaDB and MySQL 8.0 can no longer replicate freely between each other, so "switch to MariaDB first" is not a neutral intermediate step. For adjacent decisions see the Oracle to PostgreSQL guide and the comparison FAQ.
Related pages
- PostgreSQL vs MySQL — the upstream of the MariaDB fork, and the shared behavioral traps
- PostgreSQL lineage and compatible databases — systems that reuse PostgreSQL itself
- Extensions ecosystem — what "choose PostgreSQL" includes
Last updated on
PostgreSQL vs MySQL
Governance, licensing, 2026 version status, capability and behavior differences between PostgreSQL and MySQL — and when each is the honest choice
Oracle to PostgreSQL Migration Guide
A complete Oracle-to-PostgreSQL migration guide — compatibility differences, three migration routes, assessment and CDC tooling, and a five-phase cutover process.