SurrealDB：一个引擎里同时装下文档、图、关系、向量与时序

「Koala 聊开源」当时介绍 SurrealDB 的点是：它同时支持 table、document、graph 多种数据模型，对外暴露 SurrealQL、GraphQL、REST 与 WebSocket 多种查询方式，支持实时查询与行级权限，既能嵌入式部署，也能上云扩展为分布式数据库。几年过去，SurrealDB 的工程内核没有变，但它的市场叙事已经明显转向——官网首页如今把自己称为「The context and memory layer for AI agents」（AI Agent 的上下文与记忆层）。本文基于其官网与 GitHub 仓库，还原这个多模型数据库的真实能力，并客观看待它的定位漂移。

一、背景：为什么要「多模型合一」

传统应用往往要拼装好几个数据库：关系库存业务事务、文档库存半结构化数据、图数据库做关系遍历、向量库存检索、时序库存指标。每多一种引擎，就多一份运维、多一份数据同步与一致性负担。SurrealDB 的出发点就是用一个引擎统一这些模型，从而「移除大部分服务端组件」，让开发者更快、更便宜地构建安全、高性能的应用。它官方列举的用例包括：需要多种数据类型的数据密集型系统、AI Agent 的数据层、知识图谱、实时应用（推荐引擎、风控检测等）。

二、是什么：Rust 写的多模型数据库

GitHub 仓库的定义很准确：SurrealDB 是「一个用 Rust 构建的多模型数据库，旨在把多种数据模型统一进单一引擎」。它原生支持的模型包括：

• 文档（document） 与 图（graph）；
• 关系（relational），且同时支持强 schema 与 schemaless；
• 时序（time-series）、地理空间（geospatial）；
• 键值（key-value） 与 向量（vector）。

关键在于：这些不是「插件式并存」，而是可以在一个 ACID 事务里、用一种查询语言 SurrealQL 一起查询。SurrealQL 官方称其「在一个数据库、一套对象存储之上，统一了 SQL、知识图谱、向量与全文检索、时序与键值查询」。

三、技术机制

几个值得注意的工程特性：

1. 统一查询语言 SurrealQL：把关系查询、图遍历、向量/全文检索、时间旅行（temporal）揉进同一套语法，开发者不必在 SQL 与图查询语言之间切换；
2. 行级/字段级权限：可在角色、记录、字段三个层级定义权限，让每个用户、服务或 Agent 只能看到和修改它该碰的数据——这是它能直接当「数据 API 层」的基础；
3. 实时能力：内置 live queries 与 change streams，客户端能在一条写入提交时立刻收到变更推送；
4. 部署弹性：既可作为嵌入式库/单二进制跑在应用内，也可在云端扩展为托管的分布式集群（Cloud 提供可选云厂商与区域）；
5. 为 AI Agent 重构叙事：2026 年的官网把「Agent Memory」单列为一大板块，强调「把图遍历与向量检索结合」「带来源与时间的可查询持久记忆」「事实被新事实覆盖但保留历史」，并提供 MCP 接入。

四、关键事实（官方口径）

五、评测方法与口径批判

SurrealDB 官方没有在 README/首页给出与 Postgres/MongoDB/Neo4j 的同场 benchmark 数字，其传播主要靠「一个引擎替代多个」的架构叙事与客户 logo。阅读时要保持清醒：

• 「一个引擎统一多模型」是工程便利，但单一引擎在每种单项能力上通常不如专用数据库——向量检索比不过专用向量库、图遍历比不过原生图数据库、关系事务比不过成熟 Postgres；它赢在集成，不一定赢在单点极致；
• 「移除大部分服务端组件」指它内建了 API 与权限层，减少了胶水代码，但并不等于不需要建模、调优与运维；
• 客户墙（ING、British Airways、NVIDIA）只证明有大公司在试用或局部采用，不代表其在这些公司核心链路承担了全部数据负载；
• 从「实时 Web 的多模型数据库」到「AI Agent 记忆层」的叙事转向，说明其产品定位仍在快速寻找市场，早期承诺的能力边界需要以最新文档为准。

六、适用与不适用场景

适合：

• 想要一个引擎同时承载关系、文档、图、向量查询，减少多套数据库拼装的团队；
• 实时应用、需要行级权限与内置 API 层的 BaaS 类场景；
• AI Agent 应用，希望把结构化关系、向量检索与变更流放在一起做记忆/上下文；
• 嵌入式或边缘部署，偏好 Rust 单二进制。

不适合：

• 已有成熟 Postgres/Mongo/图库生态、且对单项性能有极致要求的核心系统；
• 需要庞大第三方工具链、稳定长期兼容性的保守企业；
• 对「什么都能做」保持怀疑、更倾向专用组件组合的工程团队。

七、客观分析：优势与局限

优势：

1. 真多模型：文档/图/关系/向量/时序在一个 ACID 引擎内统一查询，集成成本低；
2. 内建 API 与权限：行级字段级权限 + 实时推送，天然适合做数据 API 层；
3. 部署灵活：嵌入式到分布式云，跨度大；
4. 顺势 AI：把向量检索与图遍历结合做 Agent 记忆，切中当下需求。

局限：

1. 单点能力未必专精：作为通用多模型库，各单项难敌专用系统；
2. 生态与成熟度：对比 Postgres/Mongo，工具链、社区资料与长期案例仍在积累；
3. 定位漂移：从实时 Web 到 AI 记忆层，产品重心仍在探索，早期用户需跟踪路线图；
4. 锁定风险：SurrealQL 与内建 API 层带来便利，也带来一定程度的生态绑定。

八、它意味着什么

SurrealDB 是「多模型数据库」这一品类在 Rust 时代的代表：它不追求在某一个维度上做到极致，而是赌「把文档、图、关系、向量、时序捏在一起、用一种语言查」本身就是价值。对正在为「要不要同时维护五个数据库」发愁的团队，它提供了一个有吸引力的整合方案；但如果你已经有一套跑得很好的专用栈，迁移过来的边际收益需要认真做 POC 验证，而不是被「一个引擎全搞定」的叙事说服。

参考来源

• SurrealDB 官网
• surrealdb/surrealdb GitHub
• Koala 项目库条目 #1204