MariaDB/server

MariaDB Server 是一个成熟的关系型数据库，与 MySQL 保持较高兼容度，适合作为迁移目标，并在此基础上发展出了自己的功能。如果你的应用本来就按 MySQL 编写，或者你想自托管一个熟悉的 SQL 服务器，MariaDB 值得评估；如果你依赖云厂商 MySQL 的专有扩展，或者只想要一个功能面很小的单引擎数据库，那么对比的重点不在功能列表上。

解决什么问题

团队有一个按 MySQL 编写的应用，或者正准备开始一个新项目，希望使用一个熟悉且能自己运行的 SQL 服务器。麻烦通常出现在三个地方：想要一些原生 MySQL 没有的功能，想要适合特定负载的存储引擎，想要同步集群但不想再引入一套分布式系统。MariaDB 改变的是中间这一步：这些能力都放在同一个服务器里，应用的 SQL 不用改，运维需要做的选择从「用哪个数据库」变成了「用哪个存储引擎、哪种复制拓扑」。

有什么不同

最显眼的新增能力是原生 VECTOR 数据类型和基于 HNSW 的近似最近邻索引，从 MariaDB 11.8 开始可用，不需要额外扩展。如果你的向量嵌入需要和普通关系数据放在一起、并在同一个 SQL 会话里查询，这一点有实际价值，可以少维护一个独立的向量数据库。代价是你要绑定 MariaDB 自己的向量实现和它的版本节奏，所以应当核对你依赖的索引行为和查询语法，而不是假设它和专门的向量存储一致。

更根本的差异是插件式存储引擎架构。InnoDB 是事务型负载的默认引擎，Aria、MyRocks、面向分析的 ColumnStore、用于分片的 Spider 和用于归档的 S3 覆盖其他类型的工作。复制支持异步、半同步和并行模式，带全局事务 ID，Galera 提供同步多主集群。高级 SQL 包括 CTE、窗口函数、系统版本化表、序列和 JSON 函数。兼容性覆盖 MySQL 的线路协议和语法，另外还有支持 PL/SQL 风格存储例程的 Oracle SQL 模式。这种广度既是好处也是成本：更多引擎和模式意味着更多需要记录的选择，也意味着针对你的具体负载需要测试的面更大。

谁值得试

适合的场景：已有 MySQL 兼容应用、希望自托管，或者需要 Galera 风格的同步集群，又或者想在不额外运维一个数据库的前提下试用向量检索。能接受在同一个服务器里使用 ColumnStore 的分析型工作负载也算合理。不适合的场景：依赖某个云厂商托管 MySQL 及其专有扩展的团队，或者只想要单引擎、功能面尽量小的团队。

使用条件与边界

许可证是 GPLv2，且没有「任何后续版本」条款，这是从 MySQL 继承来的，嵌入或再分发之前应当仔细阅读许可证和第三方声明。发布节奏是每年一个 LTS 加每季度滚动版本：二进制 LTS 维护三年，推荐用于生产；滚动版本更快带来新功能，但支持窗口更短。在两者之间做选择是一项持续的维护决策，而不是一次性的安装选择。官方为受支持的平台提供安装包，从源码构建则需要按照开发者指南选择正确的分支并运行测试套件。向量检索功能受版本限制，11.8 起才有，所以要确认你的部署目标确实包含它。

HotRepo 点评

HotRepo 只在 2026-10-27 的记录中看到 MariaDB 登上过日榜一次，当天 8,457 stars、+8；只有一个记录日期，无法判断关注度能否持续。2026-08-04 有一个关于在服务器日志中推广 star 的 Hacker News 帖子获得 64 分、23 条评论，这只说明讨论量，不代表社区意见。采用之前，建议先确认原生向量检索从哪个版本开始可用、以及它和你的复制配置如何配合，这是最值得先弄清楚的兼容性问题。

项目源码与说明