数据库的用户，正在从人变成 Agent

在拆两家的方案之前，有一个背景变化必须先讲清楚，因为它直接决定了我们用什么标准来评价一个 AI 数据库。

过去数据库是给人用的。工程师写 SQL 查一条订单，分析师跑一张报表，DBA 做个备份恢复。这些操作是确定性的、低频的、有人看着的。

但情况已经完全不同了。

Agent 成了数据库的主要消费者，它们的行为跟人完全不一样：

全天候不间断地调数据，不是“上班时间查一下”，而是 7×24 持续读写。混合检索，不是只查结构化字段，而是同时检索文本、向量、JSON、图，一次拿到完整上下文。会犯错，而且犯错的方式是直接改了线上数据。数量爆炸，蚂蚁的灵光平台几个月就承载了 3000 多万个闪应用，妙思在内部上线了上万个应用，平均每个只有百来行数据。

Databricks CEO Ali Ghodsi 自己也说了一个数据：他们平台上，现在大约 80% 的数据库实例是被 Agent 创建的，不是人创建的。

所以评价一个 AI 数据库，得看它能不能同时回答好这几个问题：数据一致性在 Agent 高并发读写下能不能扛住？多模态数据能不能统一管理？Agent 试错会不会搞坏生产环境？海量小库能不能低成本共存？这些能力有没有经过生产环境的真实验证？

带着这几个问题，来看两家的方案。

Databricks LTAP：从湖出发，给湖加上事务引擎

Databricks 的路线非常清晰。

它原来就是做湖仓的，Spark、Delta Lake、Unity Catalog 是它的地基。LTAP 是在这个地基上加了一个事务引擎 Lakebase。

Lakebase 是什么？简单说，就是一个跑在对象存储上的 Serverless Postgres。Databricks 去年花了大约 10 亿美金收购了 Neon（一家做 Serverless Postgres 的公司），然后把 Neon 的存算分离架构和自己的 Lakehouse 做了集成。

LTAP 的核心设计思路是“在存储层统一，而不是在引擎层统一”。Postgres 负责事务，Lakehouse 引擎负责分析，两个引擎共享一份底层数据（Delta/Iceberg 格式存在对象存储上），不再需要 CDC 管道在中间搬数据。

这个思路很聪明，让每种负载用最合适的引擎处理，通过共享存储层消除数据搬运。

公平地说，Databricks LTAP 有几个点做得确实不错：

存算分离和 Scale-to-Zero。这个对 Agent 场景很关键。每天 1200 万次数据库启动，闲时资源归零，这个弹性能力很强。

Git 风格的分支。最新版 Lakebase 也支持数据库分支和快照了，可以从生产库拉一个分支做实验。

开放格式。数据以 Delta 和 Iceberg 格式存储，不被锁定在某一家的专有系统里。

Lakehouse//RT。新出的实时查询引擎，在 Delta/Iceberg 表上做到亚秒级延迟，解决了分析层的低延迟问题。

这些能力对于数据分析、BI 看板、轻量级应用后端是够用的。

但问题来了。

两条路线，天然的能力侧重不同

Databricks 从湖出发，OceanBase 从库出发。出发点不同，天然擅长的东西就不同。

Databricks 的底子是湖仓。它做数据分析、做 ETL、做机器学习训练，全球范围确实是标杆。事务处理这一块，是它通过收购 Neon、推出 Lakebase 之后才补上的能力，时间还不长。

这不是好坏的问题，而是每条路线都有自己的起点。几个维度上的差异值得注意：

事务架构不同。Lakebase 基于 Postgres，Postgres 是优秀的单机事务数据库，ACID 能力成熟。但它不是原生分布式的。当 Agent 需要跨多个分片做强一致的事务操作时，单机事务语义和分布式事务语义的差异就会显现出来。

多模态能力的深度不同。Lakebase 新增了向量搜索和全文搜索能力，但底层仍然是 Postgres 的表结构。像结构化字段、文本、图片、音视频、向量在同一张表里统一存储、统一事务、统一权限，这种原生多模态的设计思路，两家走的方向不一样。

生产场景的积累不同。Databricks 的强项在数据分析和 AI 训练场景，Lakebase 目前的客户主要是互联网应用后端。而 OceanBase 在金融核心系统、大型银&行、保险、证券这些对一致性和可靠性要求最苛刻的场景里，已经积累了十几年。

这些差异不是谁好谁差，而是从湖出发和从库出发这两条路线的天然起点不同。

OceanBase 湖库一体：从库出发，把湖的能力长进来

OceanBase 走的是相反的路线。它原来就是做数据库的，而且是在中国最严苛的金融场景里被打磨出来的数据库。

15 年来做的核心事情就是事务一致性、分布式可靠性、弹性扩展这些底层能力。

现在它要做的是：在这些已经验证过的能力之上，把数据湖的开放、海量、多模态能力加进来。

从技术架构上看，OceanBase Lakebase 的设计跟 Databricks 有一个根本区别，它是在引擎层做融合，不只是在存储层。

具体来说，有几个能力值得单独拎出来看：

多模表。这个可以说是这次最值得关注的设计。一张表里可以同时放结构化字段、JSON、文本、图片、音视频（LOB）、向量。用户看到的还是一张表，但背后非结构化数据跟结构化数据在同一套事务、权限、元数据、版本管理体系里。

你想想，一张合同表里能同时存合同编号、合同 PDF、正文摘要、关键条款 JSON、摘要向量、风险标签。这些过去散落在业务库、对象存储、搜索引擎、向量库里的东西，现在在一张表里搞定了。

AI 列。在多模表基础上还有一个 AI 列的概念。数据写入后，可以在库内直接生成摘要、标签、向量等结果，不需要把数据导出到外部做 Embedding 再写回来。更重要的是，它保证了事务一致性，一批数据的向量化，要么全部成功，要么全部失败。

做过 RAG 的人应该对这个深有体会：向量化任务跑一半挂了，一半旧向量一半新向量，后面召回质量就变得很“玄学”。

混合搜索。关系过滤、全文搜索、向量搜索、图搜索在引擎层统一完成，一条 SQL 组合执行。数据库先缩小范围做粗排，模型只处理高价值候选。

在 VectorDB Benchmark 上，同等召回率下向量搜索性能领先 Milvus、PGVector 和 Elasticsearch。混合搜索用 MSMARCO 数据集测，性能比 Elasticsearch 好 30% 以上。

Fork Database。这个能力跟 Databricks 的 Git-style 分支思路类似，但在生产场景里验证得更深。蚂蚁的阿福（服务上亿用户的 AI 健康应用）在做 Agent 评测的时候，需要十几个 feature 分支以周为单位并行迭代，每个分支都需要完整的数据环境做评测。Branch 能力可以毫秒级创建数据沙箱，5 分钟拉齐一个评测环境，用完直接销毁。Agent 改错了，丢掉分支从主干重新拉就行。

海量逻辑表。这个是针对“小库太多”问题给出的特有方案。灵光 3000 多万个闪应用，每个应用只有百行数据，如果每个都建物理表，schema 直接爆炸。逻辑表让每个 Agent 看到的是独立的表，底层收敛到共享物理表里，配合闲时归零、按需唤醒，解决海量小库的成本和隔离问题。

核心差异：事务一致性和生产验证

说了这么多，两家最大的差异到底在哪儿？

可以归结为两个词：事务一致性和生产验证。

事务一致性方面，OceanBase 是原生分布式架构，十几年的金融级事务能力不是从 Postgres 那里借来的。它在分布式多副本之间保持强一致，在多模态数据的写入和检索之间保持事务语义，在多个计算引擎共享数据的时候通过 Unified Catalog 做统一权限控制。

Databricks Lakebase 底层是 Postgres，Postgres 的 ACID 当然没问题，但那是单机语义。当业务真的跑在分布式环境里，需要跨节点事务、需要多模态数据的一致性保证、需要 Agent 在隔离沙箱里操作而不影响生产，这些场景下原生分布式的 ACID 和 Postgres 套壳的 ACID 是不一样的。

生产验证方面，OceanBase 已经服务了 4000 多家客户，包括超过 400 家金融机构，近七成万亿级资产规模的银&行把核心系统建在它上面。同时它是唯一同时刷新 TPC-C 和 TPC-H 世界纪录的数据库。这个不是 PPT 数字，是真实生产环境里沉淀下来的能力。

Databricks Lakebase GA 才几个月，LTAP 发布才两周。它的分析能力毋庸置疑，但事务处理能力和企业核心系统的生产验证，确实需要更多时间去积累。

如果说 Databricks 的 LTAP 像是为敏捷开发量身定做的“快刀”，那 OceanBase 更像是在复杂系统里锻造出来的“盾牌”。

对于金融级场景，数据的正确性、ACID 的严格保证以及在高频并发下的极端稳定，这些是没法通过单机引擎拼凑出来的，得在分布式内核中一点一点长出来。

一体化 vs 分层组合：两种设计哲学

这两家的路线之争，其实也反映了数据库设计上一个很经典的哲学分歧。

Databricks 选择的是“分层组合”。存储层统一，引擎层保持独立，每种负载用最合适的引擎。这个设计的好处是灵活，但问题是当不同引擎之间需要共享状态、保持一致性的时候，接缝处的复杂度会上来。

OceanBase 选择的是“引擎层融合”。在一套引擎里同时处理 TP、AP、搜索、AI 计算。好处是一致性天然有保障，缺点是引擎本身的工程复杂度极高。

哪种更好？这不能脱离场景空谈。

如果你的核心需求是在已有的 Databricks 生态里快速搭一个应用后端，Lakebase 确实很方便。

但如果你的 Agent 要进核心业务系统，要碰交易数据、风控规则、合规流程，数据不能错、系统不能断、故障要秒级恢复。这些场景下，从库出发的路线天然有优势，因为这些能力本来就是它的老本行。

产品体系：不止是一个引擎

顺便说一下，OceanBase 这次发的不只是 Lakebase 引擎，而是一整套产品家族：

Lakebase 是底层湖库引擎。

DataStudio 是数据开发治理平台，覆盖数据集成、加工、治理、服务发布和资产管理。

DataPilot 是面向业务人员的数据智能 Agent，可以用自然语言做经营分析、归因分析、报告生成。再加上之前发布的 PowerMem（Agent 记忆体）、PowerRAG（企业知识库）和 seekdb（开源 AI 混合搜索数据库），形成了从底层引擎到上层应用的完整链路。

写在最后

湖库一体这个方向，两家的判断是一致的：AI 时代，企业不可能继续维护一堆割裂的系统来服务 Agent。

但路线不同。

Databricks 从湖出发加事务，OceanBase 从库出发加湖。方向一样，起点不同，短板也不同。

对企业来说，选哪条路，取决于你最不能妥协的是什么。

如果是分析生态和开放格式，Databricks 的积累确实深厚。

如果是事务一致性、生产级可靠性、和金融级场景验证，这些在 Agent 进入核心业务之后只会变得更重要的东西，OceanBase 的底子更厚。

从行业视角来看，当 Agent 真正开始接手企业的核心生产任务，不只是回答问题、不只是查查数据，而是写数据、改流程、做决策的时候，那些在金融场景里被锤炼了十几年的能力，会变得前所未有地重要。

因为 Agent 不像人。

人会犹豫，Agent 会直接开干。

这时候数据库的底线能力，就是企业 AI 的安全边界。