PolarDB，如何率先赢得通往 AI 时代的半张门票？

搬开数据库的三座历史大山，PolarDB 让大一统的数据库走向前台。

作者｜Cynthia

编辑｜郑玄

AI 时代的入场券正被一分为二。

一半攥在大模型手里，以一周一迭代、一月一颠覆的速度卷出了新高度：LMArena.ai 数据显示，自 2023 年年中起，SOTA（当前最优模型）的迭代周期被压缩至 35 天，短短 5 个月就可能跌出 Top5，7 个月后连 Top10 的门槛都摸不到。

另一半则藏在数据深处：

与模型侧你方唱罢我登场的热闹不同，AI 时代，数据正变得越来越多元、异构、海量，这也导致数据侧的困境隐秘而庞大：IDC 数据显示，数据总量占比 80% 的非结构化数据仍在沉睡，此外，MIT 报告《2025 年商业 AI 现状》披露，全球 95% 的组织在 GEN AI 转型上获得的回报为零，而数据是影响成败的核心原因。

关于 AI 的发展阶段，阿里巴巴集团 CEO 吴泳铭在 2025 年云栖大会期间，阐述了通往 ASI 的三阶段演进路线：

当前的 AI 已经完成了「学习人」的「智能涌现」第一阶段；当下我们处在「辅助人」的第二阶段，AI 能够自主行动与真实物理世界交互，解决复杂任务；而长期来看，能够自我迭代超越人类的超级智能（ASI）才是我们的终极目标。

即便大模型搞定了通往 AGI 时代的 100 种解法，但随着用户需求从 AGI 向 ASI 的升级，数据的桎梏，也会让人工智能停留在无法解决实际问题、无法与真实世界产生持续互动的无知天才阶段。

那么如何抓住数据，这通往 AI 时代的半张门票？PolarDB 的答案，或许值得所有人参考。

01

大一统与碎片化轮回，

Agentic Al 时代需要什么样的数据库

数据库行业的发展史，本质上是一部问题倒逼进化的轮回大戏。

1970 年，IBM 研究员埃德加·科德的《大型共享数据库的关系模型》《A Relational Modelof Data for Large Shared Data Banks》一文，为关系型数据库埋下理论的火种；到了 1979 年 Oracle 推出首个商用 SQL 数据库，正式开启结构化数据为王的时代。

彼时的数据库，主打结构化数据管理、强事务一致性与 SQL 语言标准化，完美适配企业级应用对数据完整性的严苛要求。而迄今为止，银行核心交易、航空订票系统等强事务场景，仍离不开 SQL 数据库的加持。市场侧，则是 Oracle、IBM DB2、Microsoft SQL Server 长期垄断市场，开源的 MySQL 则在互联网场景中站稳脚跟，形成稳定的诸侯格局。

但 20 年后，互联网浪潮的到来，直接击碎了这份稳定。

2000-2010 年期间，Web2.0 与云计算的普及，让传统关系型数据库暴露出三大致命短板：分布式扩展成本高企，面对 JSON、图片等非结构化数据束手无策，高并发读写场景下性能直接宕机。

在这一背景下，2009 年 MongoDB 发布、2010 年 Cassandra 开源，NoSQL 运动全面爆发，行业思路从大一统转向专用化，并迅速分化出四大分支：文档型搞定内容管理，键值型撑起缓存会话，列族型承接物联网时序数据，图数据库深耕社交图谱。数据库与数据湖也在此期间分道扬镳：前者侧重写入实时性，后者主打读取时的海量低成本存储。

云计算企业也趁着分布式的浪潮，推出了自己的产品。阿里云正是在这场浪潮中孕育了云原生数据库 PolarDB。这款数据库从诞生起就带着云原生基因，后来逐步从阿里内部走向公开云，服务外部用户。

这种互联网与云服务时期的数据库碎片化革命带来了场景爆发，也制造了新的混乱。一个中型互联网企业，内部数据库数量动辄几十上百，运维人员每天在不同数据库间搬运数据，同一份数据，既要存在 MySQL 供交易调用，又要同步到 MongoDB 做用户画像，还要导入 HBase 存时序行为，数据冗余率飙升的同时，孤岛问题愈演愈烈。

直至大模型的爆发，彻底改写了数据库的进化逻辑。

向量逐渐成为结构化、半结构化、多模态数据的统一语言，结构化数据用稀疏向量表达，非结构化数据用稠密向量解析，数据库行业迎来第二次轮回：从专用化向一体化回归。其中，Oracle 最新版本已支持 10+数据类型，MongoDB 实现多存储一体化，PostgreSQL 凭借原生 JSON 与向量引擎成为开源标杆，Not Only SQL 的大一统趋势愈发清晰。

但趋势明朗不代表落地顺畅。不同数据类型对资源、性能的需求天差地别：交易型数据要低延迟，分析型数据要高吞吐，向量数据要高维检索能力，如何在一个架构里兼顾所有需求？

更关键的是，AI 时代的数据库不再是针对后端开发的隐形工具，前端、产品、运营都要通过 Agent 或知识库直接调用，那么如何更加适配这种数据库 Agent 前端化的大趋势，如何适配非技术用户，降低使用门槛？

All-in-One、适配 Agent 交互、降低使用门槛，成为横在所有数据库厂商面前的三座大山。

02

搬开三座大山，

PolarDB 让大一统的数据库走向前台

All-in-One、适配 Agent 交互、降低使用门槛，看似是三个不同问题，但本质上都在回答一个问题，我们要如何打造一个 AI-Ready 的数据库产品。

对于这个问题，在 2026 阿里云 PolarDB 开发者大会上宣布能力大更新的云原生数据库 PolarDB，没有走头痛医头的老路，而是从架构底层重构，给出了 AI-Ready 的系统级解决方案。

针对传统的数据库产品山头林立、数据被多次存储带来的割裂问题，PolarDB 借助 Lakebase 架构，通过湖库一体化存储、泛元数据统一管理、多引擎多模态融合检索，实现了不同类型数据以及数据管理任务的无缝协同。

首先是存储层，引入 Lakebase 概念，通过热-温-冷分层管理，精准解决性能与成本的矛盾。Lakebase 采用 NVMe SSD+OSS 对象存储的混合架构，热数据（高频交易、实时推理数据）存于高性能 SSD 达成高效响应，温数据（高频访问的历史数据）保留在 SSD 缓存层，冷数据（归档数据、低访问频次多模态文件）自动迁移至 OSS，存储成本直降数倍。这种分层不是静态配置，而是基于访问频率动态调整，搭配用户态 I/O 与网络栈设计、RDMA 技术，数据访问延迟较传统架构显著降低，兼顾高并发与高可用。

泛元数据管理则是打破数据孤岛的导航图。与传统元数据仅记录结构信息不同，PolarDB 的泛元数据分为三类：系统元数据定义如何存，明确存储位置、格式与权限；业务元数据定义为何用，关联业务场景与数据用途；事件元数据记录从何来，追溯数据产生、流转的全链路。三者协同，让 AI 模型能快速定位所需数据——比如理想汽车的智驾团队，通过泛元数据可直接关联传感器数据、标注信息与测试场景，无需人工梳理。

多模态检索能力则依赖多引擎协同作战。PolarDB 整合了搜索引擎、向量引擎、时序引擎、Ganos 时空引擎等六大引擎，其中向量引擎支持 HNSW 与 IVFFlat 两种索引——HNSW 适配高维向量的低延迟检索，IVFFlat 适合大规模数据的批量查询，搭配列存引擎的 OLAP 分析能力，可实现文本、图像、音视频、时空数据的跨模态联合检索。比如在哔哩哔哩的营销分析场景中，能同时检索视频内容、弹幕文本与用户行为轨迹，快速识别品牌曝光与用户反馈的关联。

更关键的是格式兼容性设计。Lakebase 支持 Iceberg、Delta Lake、Lance 等主流数据湖格式，兼容 OSS/S3 协议，企业无需重构现有数据架构，就能将历史数据、多模态文件无缝接入，迁移与适配成本大幅降低。

解决了海量异构数据的兼容问题之后，接下来如何让这些数据的使用变得更加 Agent 友好，成了新的困难。

PolarDB 的核心定位之一，是面向 Agent 应用开发的云原生数据库，其整体设计围绕 Agent 的两大核心需求展开：高效记忆管理与低成本开发部署。

过去，大模型的健忘症，一直是 Agent 落地的核心障碍：受上下文窗口限制，跨会话记忆无法留存，导致服务连贯性差。PolarDB 通过 Mem0/MemOS 框架，为 AI Agent 构建了长期记忆层，彻底解决这一问题。

Mem0 框架的核心是记忆分层与多引擎联动：将 Agent 记忆拆解为工作记忆（当前会话信息）、事实记忆（固定知识点）、情景记忆（历史交互场景），通过原生集成的 PGVector 向量引擎与 Apache AGE 图引擎，实现记忆的结构化存储与高效检索。

PolarDB Supabase 则让 Agent 开发从基建工程变成搭积木。过去，开源 Supabase 虽能提供一站式后端能力，但部署时需协调十多个微服务，升级过程中非常容易出现兼容问题，运维成本极高。PolarDB Supabase 则采用托管应用层+数据库核心的分离架构，将控制台、API 网关、身份认证等组件全托管，开发者通过 PolarDB 控制台就能统一配置，无需关心底层组件运维。

同时，PolarDB Supabase 中还加入了企业级增强设计：安全容器隔离防止信息泄露，内置 Realtime 实时数据库让数据变更秒级推送至 Agent，RESTful API 省去重复的增删改查编码，甚至支持通过 SQL 语句直接调用阿里云百炼内置大模型，大幅降低开发门槛。

如果说数据库接入层面的大一统以及 Agent 能力设计，针对的还是传统后端开发，那么 PolarDB 提出的模型算子化，则让非技术人员也能玩转 AI 数据处理。模型算子化（Model as an Operator）的本质是将 AI 能力封装为数据库原生算子，用户无需掌握 Python 或 MLOps 技能，用熟悉的 SQL 语言就能完成模型调用，完成分类、回归、聚类等常见需求。如此一来，数据无需迁出数据库，所有处理与推理都能在库内完成，既避免数据传输中的安全风险，又减少延迟。

03

AI-Ready 的企业，

需要 AI-Ready 的数据

如果说 PolarDB 的进化，回答了 AI-Ready 数据库如何建设的问题，那么企业如何管好数据、用好数据，也就是做好 AI-Ready 的数据，则是企业选好数据库、做好 AI 转型的前提。

而围绕 Agentic Al 时代，如何用好数据，我们可以从道与术两个方面出发去看。

道的层面，Gartner 发布的《Ready Your Data for AI》给出了答案：所谓AI 就绪的数据不是越多越好，而是要满足「连接性（Connected）、持续性（Continuous）、精选性（Curated）、上下文相关性（Contextual）」四大特性。

这四道标准与 PolarDB 的技术设计高度契合：连接性要求打破数据孤岛，对应 PolarDB 的湖库一体与泛元数据管理；持续性要求数据实时更新流转，依赖 Lakebase 的动态分层与 Realtime 能力；精选性要求数据与业务目标对齐，通过模型算子化让数据处理贴合场景需求；上下文相关性则靠泛元数据与 Agent 记忆层实现，让数据带着场景信息供 AI 调用。

术的层面，不同行业的实践给出了殊途同归的解法。

在汽车行业，理想汽车依托 PolarDB 构建智驾元数据底座，查询性能提升 3 倍、TCO 降低 60%，日推理调用量超百万，支撑智能驾驶快速迭代，并极大简化了企业 AI 转型的技术复杂度；在视频社区，哔哩哔哩通过大模型+小模型协同框架，实现数据不出库的智能营销分析，为广告主提供精准决策依据；在 AI 基座领域，MiniMax 用 PolarDB Limitless 架构解决千亿级表查询瓶颈，支撑 100+实例毫秒级响应。

当然，以上企业并非个例，截至目前，PolarDB 已服务超 2 万客户，部署规模超 300 万核，覆盖全球 86 个可用区, 成为 AI 时代数据底座的主流选择。

04

尾声

在通往超级人工智能之路的这个过程中，不仅需要模型层面的进步，更需要解决不同格式、不同来源、不同用途的数据，打破 AI 落地最后一公里的核心桎梏。

而伴随 PolarDB 这样的数据库从工具向 AI 基础设施转型：基于向量的多模态数据库让数据之间有了统一的语言，湖库一体让数据有了共同的存储管理方式；模型算子化，让数据能够更低成本的被更多人所利用。

万能的大模型+All-in-One 的数据库+丰富的工具生态，让构建 AI 应用的复杂度，变得前所未有的低门槛，AI-Ready 到 AI-Native 成为可能。

而 PolarDB 的探索，不仅给出了 AI 原生数据库的标准，也让无数企业拿到了通往 AI 时代最重要的的半张门票。

*头图来源：阿里云

本文为极客公园原创文章，转载请联系极客君微信 geekparkGO

极客一问

你如何看待PolarDB ？