10 月 16 日，GOSIM Shenzhen 2026 的 openGauss 数据库与生态协同论坛在深圳举办。我受社区邀请做了一个主题分享，题目是《AI 时代数据库生态的技术创新与实践》，并主持了最后的圆桌讨论环节。
回来之后，我把现场听到的东西，和这二十多年自己的一点观察放在一起，写成了这篇文章。分三部分：先讲我对数据库行业变化的判断，再讲我在 openGauss 这个社区里看到的方向，最后把视角拉到整个产业和生态，分析数据库的下一发展阶段。
一、行业：这一轮 AI，把数据库推到了哪里
1.1 五十多年，数据库一直在做同一件事
我从事数据库行业二十多年，在移动互联网公司带过 DBA 团队，在云厂商做过产品架构师、产品经理，也做过开源社区运营，现在在开源数据库发展联盟继续服务这个行业。我对数据库行业的判断是"热词换过很多轮，但有一条主线一直没变"：
数据库的历史，是一部不断把复杂度从应用侧收回内核的历史。
1970 年，关系模型把"怎么找数据"从程序员手里拿走，交给优化器；2000 年前后，分布式把"怎么保证一致"从架构师手里拿走，交给共识协议和复制机制。每一次收回，都是因为这类复杂度值得被工程化、被复用、被做成基础设施。
这一轮，数据库要收回的第三样东西，是
上下文
。
Agent 的"记性"——那套需要抽取、索引、召回、压缩、归档的持久化系统——现在散落在各个应用框架的业务代码里，而 Agent 框架差不多每三个月换一茬。让每个框架各自重写一遍上下文管理，是荒谬的。所以这东西该被收回来，收回到数据库。
但这次和以往两次不同：前两次收回的是"能力"，这次收回的是"责任"。收回来的上下文，要交给一个会出错的"用户"去使用。所以这一轮的主题，与其说是"快"，不如说是"边界"。
1.2 第一用户换了：从"人写的应用"，到"会自己动手的 Agent"
过去几十年，数据库面对的用户其实一直是应用——不是屏幕前的人，而是人写出来的那段代码。意图是确定的，边界是清楚的；过去几乎所有的优化，都建立在这份稳定性之上。
大模型和 Agent 打破了这个前提：它不写 SQL，说自然语言，通过协议调用数据库的工具接口；它的"上下文"就是它的数据库；它的负载特征是"大量小查询、长时间运行、状态有价值"，更像一个长跑的有状态服务，而不是短跑的无状态请求。
这里我要特别补充一句：这不是说传统应用消失了。而是 Agent 的出现，
新增了一种数据库用户
，而且从数量和使用方式上，与传统应用相比变化极大。这个变化的部分，才是今天真正值得讨论的议题。
一个可以参考的公开数据：Supabase 在 10 月的官方新闻里披露，平台累计数据库数量已达 400 万，其中约七成由 Agent 或 AI 驱动的工具创建，每月新增用户超过 100 万；同期还宣布了新一轮融资并收购 Turso，继续押注 Agent 数据库这条赛道。它给出的产品形态很直接——一个 Agent、一个任务、一个用户，对应一个库。
这个数字背后，是数据库"用户结构"的变化，而不只是"用量"的变化。
1.3 数据库从"资产"变成"中间态"
过去，数据库是资产：立项、评审、建模、上线、备份、下线，每一步都有人签字，DBA 是守门人，开一个库以天计。
现在，数据库正在变成中间态——像临时文件一样被创建、被使用、被丢弃；库的粒度从"一个系统一个库"，降到"一个任务一个库"。这是数量级上的变化。再叠加一句"空闲时只计存储成本"：数据库的存在成本，从持续计费的计算资源，变成了静止的存储。
顺着这个成本结构往下算，会碰到一个很直接的算术题：
400 万个库，由谁运维？
DBA 的数量不会增长 400 万倍。答案只能是数据库自己。
所以我的判断是：自治不是加分项，是准入门槛。没有自治，"快消式数据库"在经济上就不成立。
1.4 向量不是一种新类型，是一种新的访问模式
第二件变化，是数据形态。从 JSON、地理空间、图、时序，到这一轮最重要的——向量。
但这里有一个很多介绍都讲偏了的点：
向量不是一种新的数据类型，它是一种全新的访问模式。
数据库里，每一种数据类型背后都有一整套配套：操作符、函数、索引。传统索引回答的是"这个值等不等于""在不在这个范围里"，复杂度是对数级的；向量索引回答的是"谁离我最近"，在精确意义上必须遍历全部数据，只能用近似算法（ANN）换性能。
"近似换性能"，是向量检索和传统数据库最根本的分野。
更重要的是：真实世界里的检索，从来不是纯向量的。用户搜一个知识库，输入"怎么配置连接池参数"——这句话里同时藏着三层意图："连接池参数"是关键词，"怎么配置"是语义意图，还可能有标量过滤（金融按部门权限、电商只搜上架商品）。再复杂一点，还有属性图做连带搜索。
所以真正能落地的形态是
混合检索
：向量找相似、全文找关键词、标量做过滤、属性图做连带，四条路在同一次查询里完成。选型时应该把混合检索当成默认需求，而不是加分项。
1.5 责任边界：从"存对、查快、不丢"，到"让 AI 的输出稳定可靠"
第三件变化，是责任边界。
过去数据库的责任是九个字：存对、查快、不丢。现在多了一条：
让 AI 的输出稳定可靠。
落到工程上，这件事非常具体。AI 的输出有随机性，而数据库的 SLA 是确定性的：你不能接受"数据库偶尔会算错"，但你必须接受"模型偶尔会胡说"。
所以数据库和 AI 之间必须有明确的边界：哪些事数据库负责，哪些事模型负责，中间的接口怎么保证不出错。由此可以推出一个我认为会持续很多年的判断：数据库厂商的核心竞争力之一，是"知道自己不做什么"，以及"提高 AI 输出确定性的概率"。上下文管理、MCP、数据治理，看起来是三件事，其实都围绕同一个目标在做。
1.6 泼三盆冷水：哪些方向正在被高估
讲了变化，也得讲清楚哪些是真趋势、哪些可能被过度包装。"AI 数据库"这个词正在被稀释，我泼三盆冷水。
第一盆：把"向量数据库"当成一个独立品类，正在被重新审视。
真实 AI 应用里几乎没一个是纯向量检索：要按权限过滤、要关键词、要精排。而混合检索要求向量、全文、标量共享同一套事务、存储、权限、运维——这恰恰是"把向量塞进成熟数据库"比"再做一个数据库"更有胜算的原因。向量只是数据的一种，不是数据库的全部。
第二盆："AI 自动调优数据库"目前主要还是统计，不是有数据支撑的判断。
核心优化器依然主要靠基于代价的规则和统计信息；"让大模型自动改你的参数并且保证不劣化"，在生产环境里还远没到可以放手的程度。务实的形态是：AI 给人建议，人来决策，数据库兜底回滚。
但这里有一条明确的分水岭：如果厂商能提供
带数据证据
的建议，人工干预会少很多。比如"根据最近 7 天 1.2 万次采样，work_mem 从 4MB 调到 32MB，可以让这类查询的落盘率从 12% 降到 0.3%"——这种有量化依据的建议，和"建议调大这个参数"，完全是两码事。
第三盆："数据库内置大模型推理"是一把双刃剑。
代价是延迟不可控、可用性耦合、成本不可预测。更合理的做法也许是"旁路"：数据库提供调用模型的接口，让 AI 应用去编排，而不是让 OLTP 事务路径去依赖模型。
1.7 数据底座，正在分化出四个角色
把这些变化放在一起，会浮现一个我认为相当有解释力的判断：数据库的能力，正在沿着"数据在哪儿、谁在用、如何被使用"，分化出四个角色。
权威系统层
：管不能丢、要强一致、要复杂事务的数据。挑战是高可用、RTO、备份恢复。
语义检索层
：管 embedding、文档、多模数据。挑战是召回质量、延迟与成本之间永恒的权衡。
上下文记忆层
：管 Agent 的长期记忆——抽取、组织、索引、按需召回、压缩归档。挑战不是"能不能存"，而是"怎么正确地遗忘、怎么去伪存真"。
编排与推理层
：调模型、编排工具、处理提示词。这是大模型和 Agent 框架的地盘，数据库到这里就该退场。
我的判断是：传统数据库厂商在 Agent 时代最大的机会，可能不是"把向量做快"，而是"把记忆做对"。
理由很朴素：第一层和第二层已经很卷，能力趋向同质；第四层被大模型厂商牢牢占据；只有第三层——上下文记忆——既是数据密集型，又天然要求"存得久、管得住、省 token"，而这正好是数据库的老本行。
顺便纠正一个普遍误解：
上下文窗口不是记忆。
窗口解决的是"这一轮看见什么"，记忆要解决的是"跨会话还能被正确取回什么"。存储是已经解决的问题，难的是生命周期与治理。
二、社区：在 openGauss 这次发布里，我看到了行业的风向标
2.1 看不清方向的时候，看领军项目在做什么
我有一个习惯：当看不清未来方向的时候，就去看这个产业里的领军项目在做什么。古人在大海上航行没有方向，会看北极星。
所以第二部分，我是带着"看风向标"的心态去听 openGauss 的。
2.2 openGauss 的版本策略和仓库分层
9 月底，openGauss 7.0.0 LTS 发布。
先聊聊版本策略：LTS 每两年一次、社区承诺维护三年；创新版本每半年一次、维护半年。要上生产，LTS 是默认选择。
另外重点值得看的是 openGauss 的项目结构：openGauss 是一个非常庞大的开源项目，代码仓有数十个——内核、驱动、运维、资源池化、工具链，各有其仓。
这件事看起来只是仓库管理，其实是开源项目最难的一件事：怎么在"稳定"和"创新"之间平衡的社区治理理念。行业里不少项目死在这条线上——要么内核不敢动、慢慢僵化，要么创新直接进主干、把用户当测试环境。
内核要安全、要稳、要可扩展、要标准化
，因为它上面压着所有 LTS 用户；
生态要快速迭代、要允许试错
。所以 DataVec、BM25 这类被验证过的能力收回内核，而 MCP Server、oGMemory、oGRAC、数据分支放在独立仓库——探索的成本，没有转嫁给 LTS 用户。
2.3 高可用的三级跳：备机从"成本项"变成"产能项"
进入我认为 openGauss 最难被复制、也是我从业多年最想聊的部分：高可用。
我想用"三级跳"来讲，因为每一级跳，都在回答上一级跳留下的问题。
第一跳：资源池化。
传统主备架构有两个硬伤：存储容量翻倍，买 100TB 存储只能放 50TB 业务数据；备机要么不能读，要么读到的是旧数据。
资源池化的解法是：DSS 让主备共享一份存储，从根上消除存储翻倍；DMS 通过 RDMA 把主备内存融合，让备机支持实时一致性读。
理解这一跳的钥匙是一个概念转变：传统主备是"日志复制"，备机要重放日志，天然有延迟；资源池化是"页面交换"，备机直接看到最新页面，不存在延迟读。
效果上，sysbench 一主一备、主机读写备机只读的场景，备机性能提升 50% 到 80%；开启 OCK RDMA，备机一致性读时延至少降低 20%；算子卸载到备机后 TPCH 提升 40%；两节点 6 万 TPS、线性度 1.6 倍。
一句话：备机从纯粹的成本项，变成了有产出的产能项。
第二跳：极致 RTO。
高可用的核心指标是 RTO，通俗说就是"出故障后多久能恢复服务"。RTO 等于故障检测时间加切换时间；目标要压在 10 秒以内，检测就必须足够快。
openGauss 7.0.0 LTS 的数字是：50 万 TPMC 负载下，RTO 小于 10 秒；极致场景一主一备 70 万 tpmC、备机可读，同样小于 10 秒。配套还有并行回放优化：TPCC 备机 redo 性能提升 50% 到 100%；备机列存 TPCH 100G 相比原始行存平均 5 倍。
检测的答案，是 CM 支持订阅 SysSentry 故障事件通道，故障检测小于 1 秒——节点发生 panic、reboot 时直接感知，不等心跳超时。检测占 1 秒，给后面的切换留出 9 秒余量。
这里有个我很喜欢的细节：超节点提供的不只是性能，它直接把硬件能力兑换成了软件 SLA。
第三跳：鲲鹏超节点，把最高频的微小操作降维。
先看瓶颈在哪：资源池化下，备机判断事务可见性，要频繁通过 DMS 从主机获取 CLOG、CSNLOG、快照这些事务元数据；一条查询扫很多页很多行，就意味着成千上万次网络往返。瓶颈不在算力，在协议栈和拷贝的开销。
7.0.0 LTS 的解法是"事务快照 UB 访问加速"：把这类高频访问从"网络往返"降维成"本地内存读"。以最核心的 CLOG 加速为例——共享内存里开一个长度 2 的 32 次方、约 43 亿的槽位数组，每个槽位 16 位：14 位存 timeline，2 位存事务状态，总计正好 8GB；用 16 位原子读写避免"半读半写"。
一个 8GB 的内存条，装下了整个数据库历史上所有可能事务的状态。
这个特性背后有一个可以迁移的方法论：
找到系统里最高频的微小操作，用硬件特性把它降维——这比把某个算法写快更值钱。
2.4 oGRAC：多主多写这道"珠峰题"
还有一跳必须补充：oGRAC，共享存储多主多写。
资源池化是"一写、多读"，是 openGauss-server 的内核能力；oGRAC ——多个节点共享一份存储、都能读写。 而且是行级多写, 也就是任何行、任何表、任何数据库都可以在任意节点进行写入.
"多主多写是数据库领域的珠穆朗玛峰"，这是行业共识。开源世界里能把共享存储多主多写做到 LTS 级别的项目, 目前只有 oGRAC。我个人对 oGRAC 非常感兴趣，原因就在这里。
2.5 DataVec 和 BM25：把"像不像"和"是不是"放进同一个事务边界
回到 AI 数据能力。openGauss 的答案是 DataVec 向量引擎加 BM25 全文索引。
第一个要强调的定位：
DataVec 是内核特性，不是外挂插件。
你用普通 SQL 操作向量，不需要切换协议、不需要额外客户端、不需要另做一套数据同步——业务数据和向量在同一个事务边界、同一套权限、同一个备份恢复策略里。
这个"同库"的价值，在企业落地时是决定性的：它省下的不是几个 QPS，是治理成本。
第二个重点是索引选型。在内存受限的现实生产环境里，选错索引造成的性能损失是数量级的，不是百分比的。做容量规划，要按"索引大小除以可用内存"来算。
RabitQ 凭什么做到又省、又快、又准？先做 FHT 随机旋转减少碰撞，再做 1-bit 二值化，最后量化后精排，把损失补回来。用理论换空间，这是我认为真正的护城河。
另一半是 BM25：支持自定义 jieba 分词词典，垂直领域术语可控；可变块存储，索引空间省 40%。
2.6 oGMemory：把记忆当数据来工程化
现在回到我前半场留下的那个判断——数据库厂商最大的机会，是把记忆做对。openGauss 社区在这一层的落子是 oGMemory，2026 年 9 月开源的独立项目。
oGMemory 解决的到底是什么问题？Agent 遗忘对话早期内容，跨会话重复犯同样的错，一次该花 5 美分的查询花了 50 美分，多 Agent 协作失效，长会话上下文不断膨胀——这不是模型的问题，是基础设施问题，而这套工程恰恰是数据库擅长的事。
它最有见地的设计，我挑四个讲。
第一，七类上下文，七种写入策略。
住址用 Merge，可覆盖；历史事件用仅追加，不可变；技能经验用累积追加。对所有内容用同一种写入策略，要么丢失可变状态，要么破坏不可变历史。
第二，L0、L1、L2 分层索引，解决长文本的信号稀释。
内容越长，向量相似度反而可能越低。解法是用约 100 token 的聚焦摘要当路标、约 500 token 的概览当目录，命中后递归展开——救回那些"原文分数不高、但父主题强匹配"的内容。
第三，Token 预算不够时，先砍谁。
大多数 Agent 框架的答案是"截断最老的消息"，这在语义上是错的——最老的往往是系统提示和最初约束。oGMemory 给每类内容定优先级和不可降级性：预算再紧，宁可什么都不召回，也不能丢掉"我是谁、我在干什么"。
第四，ContextFS 的双形态。
底层可以落文件系统，也可以 DB-first——用数据库表直接承载语义节点。记忆落在你自己熟悉的数据库里，权限、审计、备份、事务、多租户隔离全部自带。
这就是"把记忆做对"的最好落地：记忆是一种数据，而把数据管好，正是数据库三十年的积累。
2.7 AIpipeline 和 MCP
最后聊一下 AIpipeline 和 MCP。
AIpipeline——库内调用模型。
传统做 RAG，应用层要干四件事：调 embedding API、存向量、查相似度、拿结果拼上下文再调 LLM。AIpipeline 说这四件事我都能做，你只管写 SQL：向量检索 20 篇，rerank 重排，取 Top 5，调 LLM 生成。它最大的价值不是性能，是降低门槛。四种模型来源里，本地 ollama 和本地 ONNX，对"数据不能出域"的场景特别重要。
配套的还有两层：DB4AI 把机器学习直接跑在库里，数据不出库——对"数据必须留在域内"的场景，这几乎是唯一可行的路，同时也是防外泄设计；DBMind 的虚拟索引让代价模型在线校准，它给的是"有量化依据的建议"，不是全自动接管。
MCP——让 Agent 用标准协议操作数据库。
这相当于 JDBC 对应用的意义，openGauss 的 MCP Server 提供 11 个工具。
这里我要完整引用官方文档里的一段话，因为我认为这是整个特性文档里最重要的一段："请注意模型理解偏差可能导致的数据误删风险，用户需要对执行命令进行审核，并且建议为数据库连接配置最小必要权限。"
MCP 解决不了"模型调错工具导致数据误删"这个风险，但 MCP 工具本身有功能边界，可以由 Agent 提醒用户授权；真正的兜底，是"人工审核加最小权限"。
换句话说：
MCP 把"能做什么"写在数据库的权限和约束里，而不是写在 prompt 里。prompt 是建议，约束是强制。
三、展望：下一阶段，技术与生态往哪里走?
3.1 要不要"再造一个数据库" ?
到底要不要为 AI 的工作负载再造一个数据库? 还是与成熟的开源数据库进行共建增加 AI 所需的功能? 答案就藏在三位嘉宾老师的分享中.
磐维：从向量数据库走向 AI 应用数据底座。
移动磐维的分享从向量存储检索出发，一路延伸到知识库服务、智能体记忆和跨智能体协同。在"聚智"智能体平台的知识库场景里，应用侧做文档解析、切片、向量化，磐维承担存储与检索，再与查询处理、结果排序、大模型生成衔接；"蜂群"这类智能体应用则把记忆管理和任务状态管理带了进来。
海量 Vastbase：面向企业 AI 的融合检索。
真实业务里的检索，往往要同时满足语义相关性和业务条件——查相似故障案例，还得考虑设备类别、发生时间和访问权限。这就逼着数据底座把向量检索和结构化条件过滤协调起来，同时兼顾数据更新、权限控制和查询性能。他们的做法是在检索能力融合、索引优化、资源利用上做优化，再结合制造、金融等行业场景落地。
国创灵梭 IntarkDB：端侧智能的数据底座。
端侧要处理传感器、控制器、视觉系统的多种数据，同时受计算、内存、存储、网络的严格限制。IntarkDB 基于 openGauss 技术路线做轻量化、多模管理和端边云协同，服务机器人码垛工作站、储能能量管理单元、船舶制造工业平板这类场景，端侧知识库还要解决"知识怎么及时更新"。
三位嘉宾老师的共同点很清楚：
没有一个是"再造一个数据库"，都是在真实业务约束里，把事务、检索、治理放回同一个产品。
这也是第一部分那个"混合检索必须是默认需求"的判断，在产业侧的回声。
3.2 圆桌上形成的四个共识
Panel 环节我担任主持，和几位分享嘉宾从用户需求和应用实践出发，聊了 openGauss 7.0.0 LTS 的能力怎么变成实际价值，以及社区和伙伴怎么深化协同。有四个共识，我觉得值得记下来。
第一，数据库面向 AI 的演进，要以具体场景需求为牵引。
端侧 Agent、AI Coding、多 Agent 协作，负载特点完全不同；记忆管理、数据分支、多模检索、多写架构这些能力，必须结合这些差异持续演进。推动 AI 应用落地，既要夯实高质量数据基础，也要从明确的业务痛点切入，用实际效果验证价值，再把成熟方案复制推广。
第二，生态的长期价值，体现在用户能否持续获得完整的应用与服务资源。
除新版本特性之外，软硬件适配、咨询交付、运维服务、技术资料与人才培养同样关键。生态建设要兼顾新技术探索和存量系统需求，形成覆盖不同应用阶段的协作体系。
第三，协同要加强应用需求与社区技术之间的双向反馈。
大家提到要加强与 Dify、RAGFlow 这类 AI 开发平台和框架的衔接，探索嵌入式数据库与服务端数据库之间的技术复用和数据协作，把场景里的共性需求与实践成果反馈到社区。
第四，存量不能被忽略。
这一点在会上被反复提到，也是我最认同的一点：AI 时代的新需求很热，但绝大多数企业的核心系统还跑在上一代架构上。生态如果只顾着往前冲，就会丢掉真正付账单的那批用户。
3.3 两条参照线：PostgreSQL 的"拼装"与 Milvus 的"补课"
上面这些判断如果只看 openGauss 一个样本，说服力是不够的。要检验"把复杂度收回内核"到底有没有意义，最好的办法是看另外两条路各自要付什么代价。
第一条路：PostgreSQL——能力都在，只是不在一个产品里
PostgreSQL 的路线非常清楚：内核只做"所有负载都需要、且必须长期稳定"的那部分，AI 需要的专属能力交给生态。
事实也确实如此。到今天，PostgreSQL 内核里没有向量类型，向量检索靠 pgvector 这个第三方扩展；中文分词要靠 pg_jieba、zhparser 这类扩展；属性图查询要靠 Apache AGE；数据分支内核里更是没有。
PostgreSQL 19 已经进入 RC 阶段、正式版预计本月发布。它的内核增量几乎全是"通用基础设施"而不是 AI 专属能力：REPACK CONCURRENTLY 让表重建不再阻塞读写、异步 I/O 的 worker 自动伸缩、autovacuum 并行化并排序优先级、pg_plan_advice 与 pg_stash_advice 用来稳定查询计划、ON CONFLICT DO SELECT 让原子 upsert 变成一条语句、WAIT FOR LSN 让只读库上的"读己之写"可编程。
更值得注意的是它撤下了什么：最受期待的 SQL/PGQ 属性图查询，在 Beta 阶段被撤回，推迟到下一个大版本。这意味着今天要做属性图，仍然得装 Apache AGE。
再看云这一侧。数据分支——Agent 时代最关键的能力之一——在 PostgreSQL 内核里根本没有。它是 Neon 用存储计算分离加 copy-on-write 做出来的：建一个分支是一次元数据操作，秒级完成、零初始存储、可以从任意时间点拉出来；Supabase 拿它做 PR 预览分支；Databricks 收下 Neon 之后做成 Lakebase，把分支、零 ETL、统一权限包装进自己的湖仓。
也就是说，PostgreSQL 缺的那块拼图，是由一家云厂商用自己的架构补上、再卖给用户的。
这条路当然不是不行——PG 生态真正的生命力就在这里：内核稳、接口开放、新需求总有人接得住。但代价同样清楚：
用户拿到的不是"一个产品"，而是"内核 + 若干插件 + 一家云厂商"的组合。
组合的麻烦在于三点。一是插件质量良莠不齐：维护者不同、发版节奏不同、许可证和版本兼容矩阵复杂，出了问题先要判断是内核的、插件的、还是云的。二是性能要自己兜：HNSW 索引的 m、ef_construction、ef_search 得自己调，索引维度还有上限，检索性能还受 vacuum、表膨胀和优化器行为影响。三是没有跨插件的代价模型：向量、全文、标量三条路要在 SQL 里自己拼，谁先过滤、谁后排序、怎么召回，靠人肉试。
所以 PostgreSQL 的路线本质是：
内核做底座，生态做增量，集成成本转移给用户。
第二条路：Milvus——专用库要反过来补通用库的课
Milvus 3.0 是今年 7 月发布的，是它历史上最大的一次架构更新。但如果你把它的功能清单读一遍，会发现一个很有意思的现象：这份清单看起来不像"向量库的新功能"，更像一份关系数据库基础课的补考名单。
可空向量、TEXT LOB、在线 schema 演进、快照（时点只读视图）、服务端 ORDER BY 与服务端聚合、分面搜索、自定义全文词典加 BM25、重写的稀疏索引、Spark DataSource V2、湖原生 External Collections。
这些能力里有一大半，关系数据库已经稳定提供了二三十年。用户默认它们存在，从不讨论——就像没人会夸一个数据库"支持可空字段"。
而到今天，Milvus 的能力边界在官方文档里写得很直白。写这一侧，它只有 insert / upsert / delete 这一级的原子性，没有跨集合、跨操作的 begin / commit 事务接口——你可以删一条、插一条，但不能把"删 A 同时插 B"放进同一个事务里。读这一侧，一致性是按四级提供的：强（strong）、有界滞后（bounded staleness，也是默认值）、会话（session）、最终（eventually），本质是用 GuaranteeTs 决定"这次的检索能看到多新的数据"，不是关系数据库那种按隔离级别划分的事务语义。
不接受的还有 JOIN：官方博客《Why AI Databases Don't Need SQL》里，"No JOINs, No subqueries"是被当成优势写出来的。
检索本身也有硬上限：官方文档明确写着，单次 ANN 检索的 limit 与 offset 之和必须小于 16384，要拿更多结果得改用 search iterator。深翻页这件事，在关系数据库里是一条 OFFSET 的事，在这里是架构级的设计约束。
长文本同样有边界：VARCHAR 的 max_length 上限是 65535 字节，官方对更长正文的建议是"改用 TEXT 字段，而不是 VARCHAR"。而 TEXT 正是 3.0 才补进来的——在此之前，超过这个长度的正文只能放在外部存储里，靠主键回表。
我必须要说清楚：这不是 Milvus 的缺点，这是它的定位。一个专用库本来就不该背通用库的全部包袱。
但它同时说明了一件事：
如果你选择了"再做一个数据库"这条路，那么迟早得补完通用库几十年的作业。
而补课这件事，难的从来不是把功能写出来。难的是把它打磨到"用户敢把核心业务放上去"：事务与并发下的正确性、故障恢复、权限与审计、备份恢复与升级兼容、长尾场景下的行为一致——这些成熟度不是设计出来的，是靠海量用户在真实业务里一个个踩出来的。代码也许三年能写完，问题清单要十年才收集得齐。
Milvus 3.0 往湖原生、往下推走，方向个人是认同的，这一点值得尊重。不过也能看出它走的每一步，都在补通用数据库早就走完的路。
所以，openGauss 把复杂度收回内核，意义到底在哪
对比完这两条路，openGauss 的选择就清楚了：它不是"又多了一个向量功能"，而是把 AI 需要的能力，放进了用户已经在用的那个产品里、那个事务边界里。
对用户来说，是"一个产品"和"一套语义"。
一张表、一个事务、一套权限、一份备份、一条 SQL。向量不是另外装的东西，是同一条 SQL 能查到的另一种索引；全文、标量、属性图的过滤和向量检索共享同一套事务、权限、审计、备份恢复、复制、多租户隔离。出问题时只有一个责任方。这件事省下的不是几个 QPS，是治理成本和信任成本——而企业真正卡住的，从来是后者。
对产业来说，是省掉两笔重复的税。
一笔叫"集成税"：每个用户自己拼生态、自己调参数、自己承担第三方插件的风险和历史包袱。另一笔叫"补课税"：每个新品类都要把通用能力重新长一遍，长一遍就要再踩一遍坑。把能力收回内核，等于把这两笔重复支出变成一次性的公共投入，再由所有用户分摊——这是基础设施最朴素的经济学。
边界也必须说清楚：收回内核不等于什么都自己做。
该收的，是"所有用户都要、而且必须共享同一套语义"的能力——事务、权限、检索、记忆。
这样再回头看 2.2 节那个分层姿态，逻辑就闭合了：DataVec 和 BM25 收回内核，因为人人的 AI 应用都要、而且必须和业务数据同边界；
该收的收，该放的放——这才是"把复杂度收回内核"的完整含义。
3.4 下一阶段，我的五个判断
基于上面的观察，我给五个判断，供讨论。
第一，上下文记忆会成为独立的一层基础设施。
以 oGMemory 为代表, 从"应用框架的一个模块"变成"有独立接口、独立治理、独立生命周期的基础设施"。判断标准很简单：当一类数据开始要求"存得久、查得准、删得掉、审得了"，它就该交给数据库。
第二，混合检索会成为默认，索引选型会成为新的核心技能。
第三，自治从卖点变成门槛，"带证据的建议"是分水岭。
AI 给建议、人做决策、数据库兜底回滚，这个形态会稳定一段时间。真正拉开差距的，是建议里有没有数据证据——差异不在模型多聪明，在数据采得多细。
第四，软硬协同重新回到主战场。
软件层优化接近极限时，跨节点访问的延迟就由互联决定。超节点、内存语义通信、共享内存加速，会成为数据库差异化的新来源。openGauss 把 RTO 压进 10 秒、把 CLOG 访问降维成本地内存读，都是这条路线的实证。
第五，生态协同从"能兼容"走向"有契约"。
过去数据库生态主要是工具链协同：迁移、校验、监控，解决"落地成本"；AI 时代多了一层——能力分工的协同。健康的协同要满足三个条件：接口是标准的、可替换的，协同才不会退化成耦合；能力边界是清晰的，边界不清的生态最后会变成每家都做全家桶、每家都不够好；
收尾：模型负责可能性，数据库负责确定性
最后用一句话收尾：
模型负责可能性，数据库负责确定性。
过去几十年，数据库对用户的承诺是"数据不丢"。AI 时代，这个承诺要续写上新的四条——让 Agent 用得对、查得准、跑得快、说得清。
而生态协同的意义，在于让每个参与者都能发挥自己的优势。众人拾柴火焰高。
digoal digoal约 22 分钟