SurrealDB 3.x fsync 基准测试：统一架构与专用存储的性能取舍

数据库基准测试最容易被忽视的变量不是硬件或查询优化器，而是 fsync。当大多数性能对比将数据停留在操作系统页缓存就返回成功时，它们测量的其实是「断电即丢」模式下的吞吐量。SurrealDB 团队在最近发布的 3.x 版本基准测试中修正了这一问题 —— 所有参与对比的数据库（Postgres、MongoDB、Neo4j、Redis、MySQL、SQLite、ArangoDB）均强制开启磁盘同步，每个提交的事务必须在刷盘确认后才向客户端返回成功。这种配置下的数字虽然比「缓存友好」的厂商宣传数据低得多，却是生产环境真正关心的持久性保证。

测试方法论：控制变量与生产级配置

本次测试使用开源的 crud-bench 工具，在裸机环境（AMD Ryzen Threadripper 9970X 32C/64T、128GB DDR5、NVMe SSD）上运行。关键配置包括：

• 持久化策略：Postgres 启用 fsync = on 和 synchronous_commit = on；MySQL 设置 innodb_flush_log_at_trx_commit = 1 和 sync_binlog = 1；MongoDB 使用 { j: true } 日志写入；SurrealDB 3.x 默认启用磁盘同步（2.x 版本默认关闭）
• 负载特征：128 个客户端、每客户端 48 并发连接，数据集 500-1500 万条混合类型记录（字符串、整数、浮点、UUID、时间戳、布尔值、嵌套对象、地理空间数据）
• 调优公平性：所有数据库均按生产指南优化 —— 调整连接池、缓冲池、WAL 检查点间隔、启用并行查询和预编译语句缓存，确保没有引擎因保守的默认配置而吃亏

这种设计排除了「用我的最佳配置对比你的出厂设置」的常见陷阱，但也意味着结果反映的是「调优后的真实持久化性能」，而非理论峰值。

核心发现：统一架构的强项与短板

写入密集型工作负载

SurrealDB 3.x 在写入场景表现突出。对比 Postgres，其创建、更新、删除操作的平均吞吐量分别是对方的 1.5 倍、1.3 倍和 1.8 倍；对比 MySQL 差距更大，写入性能达到 5-7 倍。在内存键值模式下与 Redis 对比，写入速度约为 Redis 的 3 倍，同时提供 Redis 不具备的持久化事务和完整查询语言。

这一优势部分来自存储引擎的架构选择。SurrealDB 使用类 LSM 的追加写入模式，在 fsync 强制刷盘的约束下，顺序写入的摊销成本低于 B-tree 的随机页更新。但代价是读取路径需要合并多层数据，这解释了为何在单条记录读取上 Postgres 仍保持领先。

扫描与过滤查询

最显著的改进出现在全表扫描场景。SurrealDB 3.x 相比 2.x 的非索引扫描性能提升 11894%（从 0.09 ops/s 到 11 ops/s），这源于查询执行引擎消除了早期版本中的逐行解码开销。在带谓词条件的过滤扫描中，SurrealDB 对比 MongoDB 有 2.7 倍优势，对比 Neo4j 更是达到 35 倍。

这类工作负载通常是文档和图数据库的弱点 ——MongoDB 的文档模型在跨文档过滤时需要扫描 BSON 结构，Neo4j 的图遍历优化针对的是关系型查询而非属性过滤。SurrealDB 的统一存储层将图边和文档属性编码为相同的键值结构，使得属性索引可以跨模型复用。

仍存差距的领域

基准测试也诚实暴露了短板。在批量操作（100-1000 条记录批次）上，Redis 凭借精简的协议和管道机制保持领先；在索引谓词过滤上，Postgres 30 年积累的查询优化器仍具优势；在单条文档写入上，MongoDB 的 WiredTiger 引擎在特定访问模式下更快。SurrealDB 团队已将这些列为 3.1 版本的优化目标，包括批量路径重写、基于成本的查询优化器、以及更激进的谓词下推。

嵌入式场景的意外结果

SurrealDB 的嵌入式模式（与服务器使用相同的磁盘格式和查询语言）对比 SQLite 显示出代际差距：创建操作快 85 倍，更新快 110 倍，删除快 75 倍。单条读取性能两者接近，但过滤扫描仍有 6.5 倍（无索引）到 3 倍（有索引）的优势。

这一结果对边缘计算和 AI Agent 场景有重要参考价值。当数据库需要嵌入到浏览器、手机或车载系统时，SQLite 长期以来是默认选择，但其单线程写入架构在并发场景下成为瓶颈。SurrealDB 的嵌入式引擎支持 MVCC 事务和并发读取，同时保持相同的 SurrealQL 方言，使得代码可以在本地、边缘和云端部署间无缝迁移。

架构选型的决策框架

基于当前基准数据，可以建立以下决策逻辑：

优先考虑 SurrealDB 3.x 的场景：

• 需要统一存储关系、文档、图、键值、向量等多种模型，且希望避免数据同步和一致性维护的复杂度
• 写入密集型 OLTP 工作负载，尤其是高并发短事务
• 需要嵌入式部署（IoT、边缘节点、本地 Agent 内存）且对写入性能敏感
• 全表扫描和属性过滤查询占比较高

仍考虑专用数据库的场景：

• 已有成熟的 Postgres/MongoDB 运维体系，且工作负载以索引点查为主
• 需要成熟的分布式横向扩展（当前基准为单节点，CockroachDB/TiDB 的分布式对比尚未发布）
• 重度依赖特定引擎的生态系统（如 Postgres 的扩展生态、MongoDB 的 Change Streams）
• 对图遍历查询有极致性能要求（基准尚未覆盖多跳图查询）

风险与限制： 当前基准未覆盖向量搜索（HNSW 索引）、全文检索（BM25）和多跳图遍历，而这些正是多模型数据库理论上应该展现优势的领域。SurrealDB 团队已承诺在下一轮测试中加入这些工作负载。此外，所有数据来自单节点部署，分布式场景下的一致性开销和分区性能仍是未知数。

方法论启示

这次基准测试最重要的贡献或许是方法论层面的。通过开源 crud-bench 工具、公开所有配置参数、强制统一持久化语义，SurrealDB 团队提供了一个可复现的对比框架。数据库选型中的「性能」从来不是单一数字，而是在特定一致性保证、特定硬件约束、特定调优投入下的权衡。当厂商宣传「比 X 快 Y 倍」时，值得追问的是：是在缓存模式下还是 fsync 模式下？是单条记录还是批量操作？是点查还是扫描？

对于正在评估多模型数据库的团队，建议用实际工作负载在相同持久化配置下复现测试，而非依赖厂商提供的峰值数据。SurrealDB 3.x 的结果表明，统一架构在持久化约束下的写入和扫描场景已具备生产竞争力，但在索引优化和批量吞吐上仍有追赶空间。

参考来源

• SurrealDB Benchmarks — 完整测试方法、交互式结果对比及原始数据
• SurrealDB 3.x by the numbers — 版本演进分析及各数据库详细对比数据

systems