2026年，国内数据库厂商做了一件过去十年没做过的事：把AI能力往内核里塞。
1月，阿里云PolarDB发布AI数据湖库Lakebase、模型算子化和Agent托管，7月又推出面向Agent场景的PolarDB Agentic Database；5月底，腾讯云宣布数据库产品体系面向Agent场景全面升级，推出Agent Memory和DatabaseClaw，8月发布定位于AI时代数据底座的TDSQL Nexa；6月，OceanBase把AI方向打包成OceanBase AI Database产品组合；10月底，电科金仓发布KES AI数据库，把库内语义构建、库内计算推理、库内原生数据安全管控列为三大核心能力。
四家厂商，同一年，同一个方向。这不是巧合。
先校正一个容易传错的口径：这不是「数据库公司集体转型做AI」，也不是「数据库要被大模型取代」。真实发生的是另一件事——数据库在抢AI的数据入口。谁能让大模型读懂企业私域数据，谁就保住了自己在AI架构里的位置。
一、技术账：语义层为什么必须进内核
先说清楚问题在哪。
数据库里只有表结构和字段名，没有业务含义。一个叫「客户」的字段，可能指签约客户，也可能指意向客户；一个叫「金额」的字段，在财务、销售、风控三个部门眼里是三个东西。模型无法自行判别，只能猜。
过去十几年，大型企业试过解法：在数据仓库之上搭语义层、指标平台、数据目录，自上而下统一口径。电科金仓总裁杜胜把这套做法的问题总结得很直接：外挂语义层与物理结构脱节。上层建好的语义模型，不知道下层交易系统的表结构什么时候被改、字段口径什么时候被调，同步链路一旦中断，维护成本随系统数量指数级上升。
组织层面的代价更隐蔽。下层业务系统频繁变更却不通知上层治理部门，治理部门又没有对各业务系统的管控权限，语义的新鲜度就在部门壁垒之间被消耗掉了。
这种失配不会报错，只会答错。行业研究显示，在覆盖金融、人力资源和公共安全领域的236个分析意图中，成功执行的SQL查询里出现了153次反复发生的「操作化失败」——语法没问题，结果也正常返回，但它选的阈值、时间算子或派生指标，并没有忠实捕捉用户意图。比如把「异常高风险的贷款」用固定阈值来操作化，而「异常」本质上是相对参照群体的比较判断。
这就是AI数据库要解决的真问题：不是让模型会写SQL，是让模型拿到的数据自带语义。
解法是把语义搬进内核。语义对象与物理表在同一套内核里共生，物理结构变更时，关联的语义对象像存储过程一样失效，触发重编译或人工确认，变更被推到业务人员面前，而不是消失在跨系统的同步管道里。建设方向也跟着反转：不再自上而下一次性定义全企业，而是以每个业务库为单位自下而上生长。
配套的是库内推理。向量在库内生成，语义在库内定义，推理在ONNX框架下于库内完成，数据库原有的行级权限、字段级脱敏和行为审计直接覆盖到AI链路，智能体访问数据库时复用数据库账号的权限体系。
二、商业账：从卖存储到卖「让机器读懂」
这轮产品发布背后，是一笔很清楚的市场账。
据行业机构统计，超过83%的公共数据已得到较充分开发，而企业95%以上的高价值业务数据仍沉睡在私域数据库中，其中八成以上是非结构化内容。企业最有价值的数据，大模型看不见、读不懂、用不上。
这意味着两件事。第一，过去数据库卖的是存储和计算，客户按容量和并发付费；以后要卖「语义+推理+安全」的组合能力，客户为「让机器理解数据」付费。第二，这个市场不是新增市场，是存量替换市场——客户不会为了AI再买一套数据库，只会为了AI换掉现在这套。
存量替换的周期很长，但有两个加速器。一是信创与国产替代，给了国产厂商重新进场的窗口；二是AI项目从试点走向生产环境的压力，很多项目卡在数据这一层，不换底座就上不了线。
Gartner在2026年的多项研究里提到，上下文正在成为新的关键基础设施，并预测到2030年，通用语义层将与数据平台、网络安全并列为关键基础设施。这个判断如果成立，语义层就不是数据库的一个功能模块，而是一个独立的基础设施品类。
对厂商来说，这是好事也是难事。好事是天花板打开了；难事是收费方式还没定型——按库收费、按语义对象收费、按推理调用收费，三种模式对应三种完全不同的销售组织。
三、格局账：国际厂商也在同一条路上
把视野拉到全球，方向是一致的。
甲骨文在23ai版本里把向量检索做进数据库；Snowflake和Databricks在语义层与开放表格式上持续投入；MongoDB把向量检索做进文档数据库。大家的判断相同：AI应用不会为向量检索单独买一个引擎，它会要求在已有的数据底座上直接完成。
这直接压缩了独立向量数据库的窗口期。过去两年靠「专用向量引擎」起量的公司，接下来要面对一个尴尬问题：客户的主数据库已经能做了，为什么还要多维护一套？
国内四家的竞争，短期看产品节奏，中期看生态，长期看谁能定义语义层的标准。语义层一旦成为标准，迁移成本就会从「换数据库」变成「重建业务口径」，那才是真正的护城河。
四、风险与边界
第一，语义的维护责任归谁。语义进内核，技术上解决了同步问题，组织上却把责任推到了业务部门——每个库的语义要业务自己定义、自己维护。这件事在试点项目里能靠项目组推动，在几百个库的规模上，需要一套治理机制，而多数企业还没有。
第二，库内推理的性能与隔离。推理跑在数据库内核里，会占用本来用于交易的CPU和内存。OLTP场景对延迟极度敏感，库内推理必须有严格的资源隔离和优先级控制，否则AI查询会把核心交易拖慢。
第三，客户是否愿意为「语义」单独付费。语义层的价值很难在采购阶段量化，它不像存储容量那样可以按GB报价。厂商需要把「语义」包装成可验收的交付物，否则很容易被当成附赠功能。
第四，「数据不出库」在多云场景下有边界。单库闭环能守住合规，但企业数据往往分散在多个云、多个库，跨库的语义统一仍然需要一层外部治理。库内方案解决的是单点，不是全局。
结论
这一轮AI数据库的竞争，表面上比的是谁接入了更多模型、谁支持更多模态，实际上比的是同一件事：语义能不能跟上表结构的变化。
语义一旦和物理结构脱节，模型答得越流畅，错得越自信。企业不会因为一个AI项目答错一次就放弃，但会因为答错一次而再也无法把决策交给它。
数据库过去四十年的使命是「把数据存好」。接下来十年的使命是「让机器读懂」。这两件事的难度不在一个量级，收费方式也不该在一个量级。
该文观点仅代表作者本人，企服科学平台仅提供信息存储空间服务。
