PostgreSQL Field Guide

PostgreSQL 与 MariaDB 选型

MariaDB 是 MySQL 的分支但已深度分叉——治理与许可证、2026 年版本现状、原生 VECTOR 类型、存储引擎模型，以及 MySQL/MariaDB/PostgreSQL 三方怎么选

MariaDB 于 2009 年由 MySQL 的原作者们在 Oracle 收购 Sun 前后从 MySQL 分出，但它早已不是"直接替换"：从 10.x 系列开始，它已经分叉成一个有自己的特性、发布模式和不兼容点的独立数据库。与 PostgreSQL 对比时有意思的是：两者都是社区治理的开源项目——却在 SQL 严格程度、可扩展性和架构上差异巨大。

2026-08 对照官方来源核对

本页的版本与支持陈述以 2026 年 8 月核对的官方生命周期页面为准：endoflife.date 的 MariaDB 页、mariadb.org、MariaDB 向量文档与 PostgreSQL 版本政策。涉及具体版本的细节请在依赖前复核。

治理与许可证

PostgreSQLMariaDB
主导方PostgreSQL 全球开发组，分布式社区MariaDB 基金会（非营利组织），保证代码保持开放；MariaDB plc 是主要代码贡献者，围绕它销售企业级产品
许可证PostgreSQL License——宽松的类 BSD 许可证GPLv2；基金会声明服务器"将始终以 GPLv2 保持自由开源，独立于任何商业实体"
分叉历史无（自己的血脉可追溯到 1980 年代的 POSTGRES 项目）2009 年从 MySQL 分出；5.1–5.5 紧密跟随 MySQL，从 10.0 起版本号和特性各走各路

基金会/公司的二元结构介于 PostgreSQL 的纯社区模式和 MySQL 的单一厂商所有之间：治理由基金会兜底，但大部分工程产出仍来自一家公司。

版本现状（2026 年）

MariaDB（据 endoflife.date/mariadb）：

版本2026 年 8 月时的状态
10.6 LTS社区支持已于 2026 年 7 月结束（企业支持仍在继续）
10.11 LTS社区支持至 2028 年 2 月
11.4 LTS社区支持至 2029 年 5 月——旧的 5 年社区支持政策下的最后一个系列
11.8 LTS按现行 3 年政策，社区支持至 2028 年 6 月
12.0–12.2滚动发布，每个版本只支持到下一个版本发布
12.3 LTS2026 年 5 月发布；新模式下首个 LTS——每个大版本的 .3 发布即 LTS

滚动发布每季度一次、随下一个版本发布即过期；LTS 大约每年一个，社区支持三年（11.4 及以前是五年）。一个值得注意的能力里程碑：原生 VECTOR 数据类型和向量索引在 11.7.1 落地，并在 11.8 LTS 中 GA。

PostgreSQL 在同一时点（据版本政策）：14 支持到 2026 年 11 月，15 到 18 分别支持到 2027–2030 年的 11 月，19 处于 Beta（Beta 2）、不可用于生产。每年一个大版本，每个支持五年。

与 PostgreSQL 的能力差异

PostgreSQLMariaDB
通信协议PostgreSQL 自有协议（pgwire）讲 MySQL 客户端/服务器协议——MySQL 的驱动、连接器、代理和大部分工具可原样使用
事务与隔离级别默认 READ COMMITTED；基于 MVCC 的 REPEATABLE READ 与 SERIALIZABLE（SSI）InnoDB：默认 REPEATABLE READ，配合 next-key lock
DDL 事务性多数 DDL 可随事务回滚与 MySQL 一样，DDL 触发隐式提交
JSONjsonb 二进制存储、丰富的操作符、GIN 索引JSON 是 LONGTEXT 的别名，附带 JSON_VALID 校验——文本存储，没有二进制 JSON 类型
向量检索通过 pgvector 扩展11.7.1 起有原生 VECTOR(N) 类型与向量索引，11.8 LTS 中 GA
序列（sequence）sequence 是核心对象；10 起有 identity 列10.3 起有 SEQUENCE 对象（MySQL 没有）
CTE 与窗口函数历史悠久（自 8.4 起，2009 年）10.2 起（2017 年）
存储引擎单一引擎，索引访问方法可插拔；12 起有表访问方法接口可插拔引擎：InnoDB（默认）、Aria、MyISAM，以及专用引擎——Spider 做跨服务器分片、ColumnStore 做列存分析（MariaDB Analytics 产品线）、MyRocks
复制模型内置物理流复制；10 起内置逻辑复制基于 binlog 的复制；同步多主用 Galera Cluster
扩展生态装载进服务器的扩展，可增加类型、操作符、索引方法（PostGIS、pgvector、TimescaleDB）插件 API 以存储引擎为中心；没有可比的机制来增加类型或索引方法

MariaDB 的差异化底牌是：它即插即用的 MySQL 协议生态、原生向量类型，以及让分片（Spider）或列存分析（ColumnStore）活在同一台服务器里的存储引擎模型。PostgreSQL 的底牌是更严格的语义、DDL 事务性，以及一个能改变数据库"是什么"而不仅是"怎么存"的扩展生态。

MySQL 血脉共有的行为陷阱——隐式类型转换、依赖 sql_mode 的宽松行为、由排序规则决定的大小写不敏感比较、AUTO_INCREMENT 与 identity 的差异——对 MariaDB 同样成立，已在 PostgreSQL 与 MySQL 选型中逐条列出。MariaDB 自 10.2 起默认开启 ONLY_FULL_GROUP_BY 且有 sequence，在这两点上它比 MySQL 离 PostgreSQL 稍近一些。

MySQL、MariaDB、PostgreSQL 三方怎么选

三方决策通常可以这样分解：

  1. 应用指定了 MySQL 协议（WordPress、LAMP 时代的 PHP、虚拟主机面板、只认证 MySQL 的商业软件）→ 真正的选择是 MariaDB 对 MySQL，这条轴在 PostgreSQL 与 MySQL 选型里讨论。在这条轴内：在意纯 GPL 许可、基金会治理、sequence、原生 VECTOR 类型或额外存储引擎，并且不要求与 MySQL 8.0 精确兼容时，选 MariaDB——两者分叉之深已使 MariaDB 不再是 MySQL 8.0 的直接替换。当 Oracle 支持合同、InnoDB Cluster 工具链或厂商认证是硬性要求时，选 MySQL。
  2. 新应用、没有 MySQL 生态约束 → PostgreSQL 是通常的默认项：更严格的语义、DDL 事务性，以及扩展生态（见扩展生态）。
  3. 团队经验与托管可用性在两个方向上都是正当输入——把 MariaDB 运维得很好的团队，跑它比跑一个不了解的数据库更安全；很多托管平台也只提供 MySQL/MariaDB。

很少成立的理由是跑分：三者应付普通 OLTP 负载都绰绰有余，决策的变量是语义、生态和运维。

迁移指路

MariaDB 迁 PostgreSQL 与 MySQL 迁 PostgreSQL 是同一类工程：pgloader 搬 schema 和数据，工作量集中在行为差异上（类型强转、大小写、AUTO_INCREMENT）。MariaDB 特有的检查项是它的文本型 JSON 列，以及任何 Spider/ColumnStore 表的用法——它们在 PostgreSQL 里没有直接对应物。另外注意 MariaDB 与 MySQL 8.0 之间已不能自由地互相复制，所以"先切到 MariaDB"并不是一个中立的中间步骤。相邻决策参考 Oracle 迁移到 PostgreSQL 指南与对比常见问题。

相关页面

Last updated on

On this page

治理与许可证版本现状（2026 年）与 PostgreSQL 的能力差异MySQL、MariaDB、PostgreSQL 三方怎么选迁移指路相关页面