刚看到 SurrealDB 完成 2300 万美元新一轮融资的消息我第一反应不是“又一个数据库拿到钱了”而是觉得这个从个人开发者圈子里一直口碑不错的多模型数据库终于要往更核心的基础设施方向冲了。过去几年我折腾过不少数据库方案从传统关系型到文档型再到后来为了AI项目搭过一套“Postgres 向量插件 Redis缓存”的组合拳。说实话这套组合能用但真的很累。SurrealDB 一直想做的是把文档、关系、向量这些模型塞进同一个存储引擎里再用一套类 SQL 查询语言统一操作顺带还内置了实时订阅和权限控制。这次融资明确写着用于扩展 AI 原生能力说明团队不是在蹭概念而是要在多模型这条路上继续加深。这篇文章我会从产品设计、核心语法、AI 原生化落地方案、选型对比和融资背后的行业信号这几个角度展开尽量还原一个从业者的观察也分享一些我实测下来的体会和踩坑心得。不管你是后端开发、全栈爱好者还是正在做 AI 应用落地项目的工程师应该都能从中找到有价值的信息。1. 这笔融资背后我在关注什么1.1 从开发者工具到基础设施的关键一步这次融资最值得注意的不是金额本身而是它的用途方向。公告里反复提到一个词AI 原生。如果说 SurrealDB 早期靠“多模型 实时 权限”吸引了一波技术尝鲜者那这一轮的定位显然更明确要做 AI 时代的数据底座。在我看来多模型数据库能拿大额融资本身就说明了一个问题开发者对“拼装式数据架构”已经开始疲劳了。过去做一个带 AI 功能的业务系统你得同时维护关系型数据库存业务数据、向量数据库存 Embedding、Redis 做缓存和实时状态还要在应用层写一堆同步逻辑。这套架构不是不能跑但每一层之间都有沟通成本数据一致性、部署复杂度、运维成本都会跟着涨。SurrealDB 的思路是把这个栈收编成一个产品。文档记录和关系可以用同一套语法操作向量搜索直接建立在记录之上实时的需求则交给内建 Live Query 去处理。对中小团队和独立开发者来说这种收敛非常友好因为它把“架构选型”这件事从组合题变成了填空题。融资之后团队有钱扩充引擎性能、分布式能力和周边生态了这对于想在生产环境使用的人来说是个积极信号。1.2 AI原生不是营销词而是工程选择很多人听到“AI原生数据库”会觉得是个营销标签但如果你拆开看 SurrealDB 对 AI 原生支持的技术布局会发现它确实是一个工程选择不是贴上去的时髦词。核心在于AI 应用的数据需求通常是三类混合的一类是业务实体之间的复杂关系比如用户、订单、商品一类是非结构化内容比如文章的正文、评论的文本还有一类是语义信息也就是把文本或图片转成的向量 Embedding。传统数据库擅长处理第一类和第二类的某一个侧面但很少原生支持第三类。你通常需要引入额外组件把向量数据放在另一个存储里。SurrealDB 直接引入了向量索引的类型在同一个表结构里可以定义普通的string字段也可以定义VECTOR字段。这意味着“业务数据”和“语义数据”从创建的第一刻就拥有同一个生命周期不需要在应用层去同步两份数据。这个设计对 AI 项目的意义很大尤其是做 RAG检索增强生成或者语义搜索的时候。向量不再是一个附属品而是业务模型的一部分天然随记录一起更新、一起查询。另外它的 Live Query 能力也不是传统数据库那种“定时轮询 心跳检查”的伪实时。它支持在客户端发起一个持续查询当数据变更时服务器主动推送变更结果这正好适合 AI 应用里常见的聊天消息推送、流式响应状态更新、推荐结果刷新等场景。一个数据库同时把查询、实时、向量、权限做完这才是我理解的“AI 原生”。2. 多模型数据库到底多在哪里2.1 文档、关系、向量在一个存储层里共存多模型数据库不是一个特别新的概念但过去很多实现是“多个引擎包装成一个入口”底层依然是各管各的存储。SurrealDB 比较有意思的点是它让不同的数据模型在同一个记录Record上共存这会让数据建模方式发生质的变化。你可以这样理解在传统设计里一个用户资料如果有标签、地址、社交关系三种不同类型的数据你通常要拆成三张表然后用外键关联查询时要 JOIN。在 SurrealDB 里一个用户 Record 本身就可以是一个复杂文档可以带OBJECT类型的字段也可以直接关联其他 Record。更关键的是这条记录还能被当作图结构里的一个节点通过RELATE语句和另一条记录建立带类型的关系。这种设计的好处在于当你做 AI 类应用时数据的自然形态往往就是混合的。比如一个聊天记录既需要结构化的 sender、timestamp 字段也需要保存完整的消息文本还需要给这条消息一个向量用于语义检索。如果你用传统方案可能要建两张表或者三个存储而在 SurrealDB 里这只是一个记录上的不同字段。索引可以加到这些字段上查询也可以在一条语句里把结构化条件、向量距离、关联关系全部表达出来。2.2 实时能力不是附加功能而是核心设计我第一次接触 SurrealDB 的 Live Query 时第一感受是“这不就是给数据库加了事件订阅吗”。后来真正在项目里用起来才明白它其实是把“被动查询”和“主动推送”统一到了一套语法里。设想一个在线 AI 客服场景客户端发来一条消息服务端调用大模型生成回复回复内容逐步写下数据库同时后台需要实时更新一个“当前会话状态”的面板。如果是传统架构你要么轮询数据库要么让服务端处理完大模型调用后主动推送 WebSocket 消息。无论哪种数据库本身并不感知“实时”的存在实时逻辑全在应用层手工维护。SurrealDB 的 Live Query 让数据库自己参与这个环节。你可以写一句持续查询订阅某个条件下的记录变化数据一变客户端立刻就能收到新数据。这里的实现细节我不展开但方向上它把实时能力从“组件组合”变成了“数据库内置能力”。好处不仅是少写代码更重要的是逻辑变得简单你不会遇到“轮询太频繁导致数据库压力大”还是“轮询太稀疏导致体验延迟”这类两难问题。2.3 权限内置数据库自己就能守住业务边界还有一个容易被低估的设计记录级权限。我在早期用 SurrealDB 的时候对这个能力印象最深因为它直接把“数据归属”的概念做进了数据库内核。很多 NoSQL 数据库做权限只能到表级别甚至只有“可读 / 可写”两种账号权限。这种粗粒度权限对业务型应用来说远远不够。SurrealDB 允许你在定义一张表时直接为 select、create、update、delete 各写一套条件比如用户只能查询自己创建的内容删除时必须满足某个字段等于当前登录用户 ID。这套权限判断发生在数据库内部不依赖应用层过滤也不依赖复杂的中间件。对于 AI 应用来说这一点非常关键。因为 AI 项目经常要暴露一个面向终端用户的操作接口比如聊天记录查询、个性化推荐内容如果数据库底层没有记录级隔离你就得在应用层仔细地给每个查询附加 “where user_id 当前用户” 条件。一旦漏掉一个就是数据泄露事故。SurrealDB 把这道防线下沉到了数据库层减少了很多心智负担。而且权限可以与 Live Query 一起使用意味着实时推送的内容也经过权限校验订阅者只会收到自己有权看到的数据。3. 从一个查询说起SurrealQL 的体验3.1 为什么需要一套统一的查询语言SurrealDB 没有沿用 MongoDB 的 JSON 查询风格也没有完全照搬 SQL而是推出了自己的 SurrealQL。第一次接触的人可能会觉得多学一门语言是成本但我用下来反而觉得是收益。原因在于JSON 查询对象在表达复杂关系时会变得非常绕尤其当你要同时处理嵌套文档和图关系时一层套一层的对象非常难读。SQL 虽然表达能力强但它是为关系型范式设计的处理嵌套文档时会显得别扭而且标准 SQL 对图的表达几乎为零。SurrealQL 走的是“语法上接近 SQL语义上同时覆盖文档和关系”的路线。你可以用它写类似 SQL 的过滤条件也可以用-friend-这样的语法直接沿着关系链取数据。从这个设计能看出团队的目标尽量降低关系型数据库开发者的迁移成本同时避免在文档型和图型之间做笨拙的翻译层。我自己在从 PostgreSQL 迁移一个小项目时大部分查询语句只需要微调就能跑起来这种“迁移低摩擦”是实实在在的体验优势。3.2 定义一个带向量的表到底有多简单直接在 SurrealDB 里定义一张带向量字段和索引的表整个过程可以用一段 SurrealQL 描述清楚。我用一段示意代码来说明注意不同版本对向量索引的具体写法可能稍有差异动手之前先对照官方文档。DEFINE TABLE message SCHEMAFULL; DEFINE FIELD user_id ON message TYPE string; DEFINE FIELD chat_id ON message TYPE string; DEFINE FIELD content ON message TYPE string; DEFINE FIELD embedding ON message TYPE VECTOR DIM 1536; DEFINE INDEX idx_embedding ON message FIELDS embedding TYPE VECTOR DIM 1536; DEFINE INDEX idx_chat_time ON message FIELDS chat_id, created_at;这段代码做了什么第一创建一张message表并指定为严格模式字段必须按定义写入。第二定义embedding为 1536 维的向量字段这正好是很多常见 Embedding 模型的默认输出维度。第三创建一个向量索引后续做相似度搜索时就能用到。第四创建一个普通索引用于按会话和时间快速检索。如果放在传统方案里你需要做的是在一张业务库建一张表又在向量数据库里建一个 collection然后把主键和向量对应同步起来。这里只需要一段 SurrealQL数据的所有语义都在同一个地方后续写入或者更新一条记录向量字段自动跟着记录走不需要额外的同步代码。这个体验对 AI 应用开发来说真的很加分。3.3 实时订阅与权限共同作用的形态下面是一段示意 Live Query 和权限共同使用的 SurrealQL 表达展示它们在工程里如何配合。DEFINE TABLE message PERMISSIONS FOR select, update WHERE user_id $auth.id FOR create WHERE $auth.id ! NONE FOR delete WHERE false; LIVE SELECT * FROM message WHERE chat_id room_1;我把 Live Query 写在了已经定义权限的表上。从业务角度理解这个查询的用户只能收到属于自己的消息即使订阅条件写的是chat_id room_1底层权限也会根据当前登录用户的身份进行过滤。这套机制对 AI 聊天室、协同编辑、实时推荐场景都很实用因为实时通道最容易因为忘记过滤而把不该公开的数据推给外部。从工程维护角度考虑把权限集中在数据库层还有一个隐藏好处你的服务端代码里不需要到处检查“这个人能不能看到这条记录”。业务代码专注于业务逻辑安全边界交给数据库。这不是说应用层可以完全不校验而是说多了一个坚实的兜底防线出问题的概率会小很多。4. AI 原生能力是怎么落地的4.1 向量索引与最近邻搜索的原理要让 AI 原生能力在数据库里真正落地光能存向量是没有意义的核心是要能高效地做最近邻搜索ANNApproximate Nearest Neighbor。传统数据库的索引比如 B-Tree擅长的是精确查找和范围查找但向量搜索要求的是“在高维空间里找到距离最近的 k 个点”这是一种完全不同形态的检索需求。SurrealDB 对向量索引的支持意味着它的存储引擎里加入了专门为高维向量设计的数据结构。我不过度展开内部实现但从使用者的角度你只需要知道创建 VECTOR 索引之后查询系统可以用“近似最近邻”的方式快速召回与目标向量最接近的记录。这种检索不需要遍历全表速度会比暴力扫描快几个数量级。实际项目中你会在写入记录时同时写入一段文本的 Embedding。当用户输入一个问题时先用同一个 Embedding 模型把问题转成向量然后用这个向量去数据库里做最近邻搜索召回最相关的文档片段。这个流程是 RAG 的核心链路SurrealDB 把链路里最容易出问题的“向量存储与检索”直接内置了。4.2 从静态查询到动态更新传统做法里向量数据的更新是个麻烦事。比如一篇文章被编辑了文本变了Embedding 要重新生成然后要找到向量数据库里对应的记录更新。如果更新逻辑写得不好就可能出现业务库里文章已经是新版本向量库里还是旧版本的尴尬情况检索结果自然也不准确。SurrealDB 里向量字段只是记录的一个普通字段。当业务逻辑更新一条记录时向量字段也会随之更新。这意味着你可以非常自然地把“Embedding 重新生成”这个动作挂在记录的更新流程里服务端拿到新版文本调用模型生成新向量通过一条 UPDATE 语句更新到对应记录上所有索引同步调整。不需要你在两个系统里做“双写”。这个设计的价值在 AI 应用里是持续的。比如知识库类产品的文档经常会被修改如果每次修改都要同步到外部向量库你要维护一套清晰的同步机制。而 SurrealDB 把这个机制消灭掉了更新记录和更新向量是同一个原子操作一致性天然有保障。4.3 一个 RAG 场景的完整数据流为了更容易理解 AI 原生多模型数据库在真实系统中的角色我画了一条数据流来描述一个知识库问答应用的工作方式。文档入库阶段一篇新文档进入系统服务端提取文本调用 Embedding 模型生成向量然后用一条 CREATE 语句把文本、标题、向量、作者等字段一起写入 SurrealDB。检索阶段用户提出一个问题服务端先用 Embedding 模型把问题转成向量再用向量距离函数在文档表里查找与问题语义最接近的若干篇文档。权限过滤阶段如果文档需要按用户可见范围控制查询结果会基于记录级权限自动过滤用户只能看到自己有权限访问的内容。上下文构建阶段把检索到的文档片段连同用户问题一起拼接成 Prompt发送给大模型。结果回写阶段大模型生成的回答可以写入对话记录表同时为这条回答生成向量方便后续“相关推荐”和“相似问题自动归类”等功能使用。在这个数据流里SurrealDB 承担了业务数据存储、向量检索、权限控制、实时推送等多项职责。你会发现一个完整的 RAG 应用居然可以做到只用一套存储系统就把核心链路串起来这在之前是需要“多套系统 大量胶水代码”才能实现的事情。用我的话说就是“复杂度被数据库本身消化了而不是转移给了开发者”。5. 横向对比新老方案怎么选5.1 传统组合方案的代价在 SurrealDB 这类产品成熟之前大家做 AI 应用的数据层普遍是“拼装”思路。我用一个表格来对比几种常见方案的特点方便你看清各自的优劣。方案组合优点主要代价关系型数据库 独立向量库关系型数据管理成熟向量库专注度高两套存储的同步逻辑复杂事务一致性难保证文档数据库 独立向量库文档模型灵活适合快速迭代关系表达弱数据访问需要应用层处理云数据库 插件式向量扩展复用现有运维体系上手快写入放大、索引资源消耗控制需要调优全托管后端平台交付速度快免运维灵活性受限数据模型可能不够贴近业务SurrealDB 类型的多模型方案一套存储、一套查询天然支持向量与实时生态相对年轻周边工具链还在建设中看到这个表格我并不是说传统组合方案没有价值而是想强调复杂度取舍。如果你的团队有很强的数据基础设施能力拼装方案完全可行但如果你更希望“让数据库自己把事干了”多模型方案会在减少系统数量方面带来明显收益。5.2 什么场景适合直接上 SurrealDB我把适合直接选 SurrealDB 的场景整理了一下供你对照参考。AI 聊天与消息系统需要记录聊天气泡的结构化信息、保存完整文本、为语义记忆生成向量、实时推送新消息这些需求正好命中多模型与 Live Query 的能力范围。知识库与 RAG 应用需要把文档正文、元数据和向量放在一起管理更新链路要短权限边界要清晰SurrealDB 的向量字段和记录级权限非常合适。实时仪表盘与监控面板需要订阅数据变更并实时刷新前端展示Live Query 直接推数据省掉了 WebSocket 服务端推送那一坨逻辑。中小型业务系统既有用户、订单这类关系数据又有商品描述、评论等非结构化内容还希望未来能加语义搜索一套数据库搞定可以先跑起来再演进。对于这些场景我的建议是先把核心表和查询逻辑用 SurrealQL 写出来验证一遍不需要很久你就能直观感受到“少维护一个系统”是否值得。5.3 什么情况建议再等等也有几种情况我会建议你再观望不要贸然迁移。已经全面依赖某一种数据库的成熟生态比如用了大量存储过程、复杂事务脚本、专有的备份恢复工具迁移成本会比较高。需要非常细粒度、经过长时间验证的分布式运维能力比如跨地域强一致、超大规模分区需要确认 SurrealDB 的集群方案在这个阶段是否完全匹配你的运维标准。工具链依赖很深比如团队已经习惯了某套 BI 报表系统直接连业务库换了查询语言后报表工具无法直接适配需要评估额外开发量。这不是说 SurrealDB 做不到这些而是说任何技术选型都要考虑“迁移成本 团队熟悉度”。新项目、小项目可以大胆用存量复杂系统建议先用旁路方式做试点验证没问题后再逐步扩大范围。6. 融资 2300 万美元背后的行业风向6.1 资本为什么盯上“开发者体验型数据库”这次融资释放的一个信号是资本越来越愿意为“开发者体验型基础设施”买单。过去数据库融资往往集中在性能指标上比如 TPS、延迟、容量。但这一轮 SurrealDB 强调的重点是 AI 原生的多模型体验这更像是为下一个开发者时代的入口占位。我理解这个逻辑AI 应用开发的最大瓶颈不是模型能力而是“把模型接进业务系统”的工程复杂度。如果你能让开发者用一个数据库就把数据、向量、实时、权限全搞定相当于降低了 AI 应用开发的整体门槛。这样一来数据库就不只是存储工具而是 AI 应用的操作系统底座。资本看中的正是这份“入口价值”。换句话说融资不是终点是加速器。拿到钱之后SurrealDB 大概率会在分布式能力、性能优化、周边文档和工具生态上投入更多让我们这些使用者受益。6.2 应用场景正在被 AI 应用快速拉大融资新闻里提到 AI 原生的定位我想提供一些真实场景作为佐证。除了之前反复提的知识库问答还有几个方向值得关注。AI 个性化推荐是一个例子。推荐系统需要把用户的行为序列、商品属性和向量化兴趣偏好放在一起联合查询。在 SurrealDB 里用户行为记录可以是文档商品之间的关联可以是图关系用户的兴趣偏好可以通过向量字段表示三者在同一条查询语句里可以统一处理。另一个场景是智能助手。这类产品往往需要保存多轮对话状态、按用户维度做实时会话推送同时还要支持“语义记忆”也就是事后根据内容相似度召回相关历史对话。如果分多个存储代码会非常散而 SurrealDB 的原生多模型能力正好匹配会话数据、语义向量、实时推送的三重特征。第三个场景是复杂网络分析比如安全告警关联、社交网络传播路径分析。传统的建表加 JOIN 方式在图谱深链查询上非常痛苦而 SurrealDB 的图关系语法在这种场景下会节省很多 SQL。虽然纯图数据库重但如果你只是在一个多模型数据库里用到轻量级图能力这其实是性价比非常高的选择。6.3 现实中要坦诚面对的坑最后我想说几句实在话。再好的技术方案也有它当前阶段的局限性不把这些讲清楚选型参考就没意义。第一个坑是生态成熟度。相比耕耘多年的老牌数据库SurrealDB 的周边工具、第三方接入、教程案例数量还有差距。遇到冷门问题时你可能要依赖官方文档和社区讨论而不是随便一搜就能找到答案。遇到这种情况我的建议是先在本地环境反复试验把不确定的点通过官方仓库的 issue 或 Discord 社区确认了再上生产。第二个坑是性能预期管理。多模型数据库的功能丰富必然意味着某些单一路径上不如专用数据库极致比如超大规模向量场景下的检索吞吐可能不如专门优化的向量数据库。但我认为关键是看你的实际数据量级90% 的项目根本到不了性能瓶颈程度在这之前“简单好用”带来的开发效率收益会更大。第三个坑是 SurrealQL 的版本演进。这门语言还比较年轻不同版本间可能存在语法调整。升级版本前要仔细看变更记录甚至先在测试环境把核心查询都跑一遍。我自己就有过升级小版本后某些索引写法需要修改的经历所以提醒每一位准备认真使用的人把版本变更当回事。综合来看2300 万美元融资是 SurrealDB 走向更大舞台的注脚但对普通开发者来说最有价值的是它代表的技术路线数据、向量、实时、权限正在收敛到同一个系统里。我个人在实际使用中的体会是不要一开始就想着用它替换所有存量系统选择一个新项目或者一个独立模块作为试验田把文档、向量、实时这三者的组合体验跑起来你会很快感受到多模型数据库的魔力。等到你习惯了“一条查询同时搞定业务条件和语义相似度”之后再回头看那些需要维护两套存储的日子大概就很难回去了。最后分享一个小经验从零开始接触 SurrealDB 时可以先不着急写业务代码花半小时把官方自带的沙箱环境玩清楚尤其是多模型定义和 Live Query 的部分。理解这几个概念后再去写应用会顺很多。等真正上手了你就会发现数据库原来也可以为 AI 时代设计得这么顺手。