搬開數(shù)據(jù)庫的三座歷史大山，PolarDB 讓大一統(tǒng)的數(shù)據(jù)庫走向前臺。

作者｜Cynthia

編輯｜鄭玄

AI 時代的入場券正被一分為二。

一半攥在大模型手里，以一周一迭代、一月一顛覆的速度卷出了新高度：LMArena.ai 數(shù)據(jù)顯示，自 2023 年年中起，SOTA（當前最優(yōu)模型）的迭代周期被壓縮至 35 天，短短 5 個月就可能跌出 Top5，7 個月后連 Top10 的門檻都摸不到。

另一半則藏在數(shù)據(jù)深處：

與模型側(cè)你方唱罷我登場的熱鬧不同，AI 時代，數(shù)據(jù)正變得越來越多元、異構、海量，這也導致數(shù)據(jù)側(cè)的困境隱秘而龐大：IDC 數(shù)據(jù)顯示，數(shù)據(jù)總量占比 80% 的非結(jié)構化數(shù)據(jù)仍在沉睡，此外，MIT 報告《2025 年商業(yè) AI 現(xiàn)狀》披露，全球 95% 的組織在 GEN AI 轉(zhuǎn)型上獲得的回報為零，而數(shù)據(jù)是影響成敗的核心原因。

關于 AI 的發(fā)展階段，阿里巴巴集團 CEO 吳泳銘在 2025 年云棲大會期間，闡述了通往 ASI 的三階段演進路線：

當前的 AI 已經(jīng)完成了「學習人」的「智能涌現(xiàn)」第一階段；當下我們處在「輔助人」的第二階段，AI 能夠自主行動與真實物理世界交互，解決復雜任務；而長期來看，能夠自我迭代超越人類的超級智能（ASI）才是我們的終極目標。

即便大模型搞定了通往 AGI 時代的 100 種解法，但隨著用戶需求從 AGI 向 ASI 的升級，數(shù)據(jù)的桎梏，也會讓人工智能停留在無法解決實際問題、無法與真實世界產(chǎn)生持續(xù)互動的無知天才階段。

那么如何抓住數(shù)據(jù)，這通往 AI 時代的半張門票？PolarDB 的答案，或許值得所有人參考。

01

大一統(tǒng)與碎片化輪回，

Agentic Al 時代需要什么樣的數(shù)據(jù)庫

數(shù)據(jù)庫行業(yè)的發(fā)展史，本質(zhì)上是一部問題倒逼進化的輪回大戲。

1970 年，IBM 研究員埃德加·科德的《大型共享數(shù)據(jù)庫的關系模型》《A Relational Modelof Data for Large Shared Data Banks》一文，為關系型數(shù)據(jù)庫埋下理論的火種；到了 1979 年 Oracle 推出首個商用 SQL 數(shù)據(jù)庫，正式開啟結(jié)構化數(shù)據(jù)為王的時代。

彼時的數(shù)據(jù)庫，主打結(jié)構化數(shù)據(jù)管理、強事務一致性與 SQL 語言標準化，完美適配企業(yè)級應用對數(shù)據(jù)完整性的嚴苛要求。而迄今為止，銀行核心交易、航空訂票系統(tǒng)等強事務場景，仍離不開 SQL 數(shù)據(jù)庫的加持。市場側(cè)，則是 Oracle、IBM DB2、Microsoft SQL Server 長期壟斷市場，開源的 MySQL 則在互聯(lián)網(wǎng)場景中站穩(wěn)腳跟，形成穩(wěn)定的諸侯格局。

但 20 年后，互聯(lián)網(wǎng)浪潮的到來，直接擊碎了這份穩(wěn)定。

2000-2010 年期間，Web2.0 與云計算的普及，讓傳統(tǒng)關系型數(shù)據(jù)庫暴露出三大致命短板：分布式擴展成本高企，面對 JSON、圖片等非結(jié)構化數(shù)據(jù)束手無策，高并發(fā)讀寫場景下性能直接宕機。

在這一背景下，2009 年 MongoDB 發(fā)布、2010 年 Cassandra 開源，NoSQL 運動全面爆發(fā)，行業(yè)思路從大一統(tǒng)轉(zhuǎn)向?qū)Ｓ没?，并迅速分化出四大分支：文檔型搞定內(nèi)容管理，鍵值型撐起緩存會話，列族型承接物聯(lián)網(wǎng)時序數(shù)據(jù)，圖數(shù)據(jù)庫深耕社交圖譜。數(shù)據(jù)庫與數(shù)據(jù)湖也在此期間分道揚鑣：前者側(cè)重寫入實時性，后者主打讀取時的海量低成本存儲。

云計算企業(yè)也趁著分布式的浪潮，推出了自己的產(chǎn)品。阿里云正是在這場浪潮中孕育了云原生數(shù)據(jù)庫 PolarDB。這款數(shù)據(jù)庫從誕生起就帶著云原生基因，后來逐步從阿里內(nèi)部走向公開云，服務外部用戶。

這種互聯(lián)網(wǎng)與云服務時期的數(shù)據(jù)庫碎片化革命帶來了場景爆發(fā)，也制造了新的混亂。一個中型互聯(lián)網(wǎng)企業(yè)，內(nèi)部數(shù)據(jù)庫數(shù)量動輒幾十上百，運維人員每天在不同數(shù)據(jù)庫間搬運數(shù)據(jù)，同一份數(shù)據(jù)，既要存在 MySQL 供交易調(diào)用，又要同步到 MongoDB 做用戶畫像，還要導入 HBase 存時序行為，數(shù)據(jù)冗余率飆升的同時，孤島問題愈演愈烈。

直至大模型的爆發(fā)，徹底改寫了數(shù)據(jù)庫的進化邏輯。

向量逐漸成為結(jié)構化、半結(jié)構化、多模態(tài)數(shù)據(jù)的統(tǒng)一語言，結(jié)構化數(shù)據(jù)用稀疏向量表達，非結(jié)構化數(shù)據(jù)用稠密向量解析，數(shù)據(jù)庫行業(yè)迎來第二次輪回：從專用化向一體化回歸。其中，Oracle 最新版本已支持 10+數(shù)據(jù)類型，MongoDB 實現(xiàn)多存儲一體化，PostgreSQL 憑借原生 JSON 與向量引擎成為開源標桿，Not Only SQL 的大一統(tǒng)趨勢愈發(fā)清晰。

但趨勢明朗不代表落地順暢。不同數(shù)據(jù)類型對資源、性能的需求天差地別：交易型數(shù)據(jù)要低延遲，分析型數(shù)據(jù)要高吞吐，向量數(shù)據(jù)要高維檢索能力，如何在一個架構里兼顧所有需求？

更關鍵的是，AI 時代的數(shù)據(jù)庫不再是針對后端開發(fā)的隱形工具，前端、產(chǎn)品、運營都要通過 Agent 或知識庫直接調(diào)用，那么如何更加適配這種數(shù)據(jù)庫 Agent 前端化的大趨勢，如何適配非技術用戶，降低使用門檻？

All-in-One、適配 Agent 交互、降低使用門檻，成為橫在所有數(shù)據(jù)庫廠商面前的三座大山。

02

搬開三座大山，

PolarDB 讓大一統(tǒng)的數(shù)據(jù)庫走向前臺

All-in-One、適配 Agent 交互、降低使用門檻，看似是三個不同問題，但本質(zhì)上都在回答一個問題，我們要如何打造一個 AI-Ready 的數(shù)據(jù)庫產(chǎn)品。

對于這個問題，在 2026 阿里云 PolarDB 開發(fā)者大會上宣布能力大更新的云原生數(shù)據(jù)庫 PolarDB，沒有走頭痛醫(yī)頭的老路，而是從架構底層重構，給出了 AI-Ready 的系統(tǒng)級解決方案。

針對傳統(tǒng)的數(shù)據(jù)庫產(chǎn)品山頭林立、數(shù)據(jù)被多次存儲帶來的割裂問題，PolarDB 借助 Lakebase 架構，通過湖庫一體化存儲、泛元數(shù)據(jù)統(tǒng)一管理、多引擎多模態(tài)融合檢索，實現(xiàn)了不同類型數(shù)據(jù)以及數(shù)據(jù)管理任務的無縫協(xié)同。

首先是存儲層，引入 Lakebase 概念，通過熱-溫-冷分層管理，精準解決性能與成本的矛盾。Lakebase 采用 NVMe SSD+OSS 對象存儲的混合架構，熱數(shù)據(jù)（高頻交易、實時推理數(shù)據(jù)）存于高性能 SSD 達成高效響應，溫數(shù)據(jù)（高頻訪問的歷史數(shù)據(jù)）保留在 SSD 緩存層，冷數(shù)據(jù)（歸檔數(shù)據(jù)、低訪問頻次多模態(tài)文件）自動遷移至 OSS，存儲成本直降數(shù)倍。這種分層不是靜態(tài)配置，而是基于訪問頻率動態(tài)調(diào)整，搭配用戶態(tài) I/O 與網(wǎng)絡棧設計、RDMA 技術，數(shù)據(jù)訪問延遲較傳統(tǒng)架構顯著降低，兼顧高并發(fā)與高可用。

泛元數(shù)據(jù)管理則是打破數(shù)據(jù)孤島的導航圖。與傳統(tǒng)元數(shù)據(jù)僅記錄結(jié)構信息不同，PolarDB 的泛元數(shù)據(jù)分為三類：系統(tǒng)元數(shù)據(jù)定義如何存，明確存儲位置、格式與權限；業(yè)務元數(shù)據(jù)定義為何用，關聯(lián)業(yè)務場景與數(shù)據(jù)用途；事件元數(shù)據(jù)記錄從何來，追溯數(shù)據(jù)產(chǎn)生、流轉(zhuǎn)的全鏈路。三者協(xié)同，讓 AI 模型能快速定位所需數(shù)據(jù)——比如理想汽車的智駕團隊，通過泛元數(shù)據(jù)可直接關聯(lián)傳感器數(shù)據(jù)、標注信息與測試場景，無需人工梳理。

多模態(tài)檢索能力則依賴多引擎協(xié)同作戰(zhàn)。PolarDB 整合了搜索引擎、向量引擎、時序引擎、Ganos 時空引擎等六大引擎，其中向量引擎支持 HNSW 與 IVFFlat 兩種索引——HNSW 適配高維向量的低延遲檢索，IVFFlat 適合大規(guī)模數(shù)據(jù)的批量查詢，搭配列存引擎的 OLAP 分析能力，可實現(xiàn)文本、圖像、音視頻、時空數(shù)據(jù)的跨模態(tài)聯(lián)合檢索。比如在嗶哩嗶哩的營銷分析場景中，能同時檢索視頻內(nèi)容、彈幕文本與用戶行為軌跡，快速識別品牌曝光與用戶反饋的關聯(lián)。

更關鍵的是格式兼容性設計。Lakebase 支持 Iceberg、Delta Lake、Lance 等主流數(shù)據(jù)湖格式，兼容 OSS/S3 協(xié)議，企業(yè)無需重構現(xiàn)有數(shù)據(jù)架構，就能將歷史數(shù)據(jù)、多模態(tài)文件無縫接入，遷移與適配成本大幅降低。

解決了海量異構數(shù)據(jù)的兼容問題之后，接下來如何讓這些數(shù)據(jù)的使用變得更加 Agent 友好，成了新的困難。

PolarDB 的核心定位之一，是面向 Agent 應用開發(fā)的云原生數(shù)據(jù)庫，其整體設計圍繞 Agent 的兩大核心需求展開：高效記憶管理與低成本開發(fā)部署。

過去，大模型的健忘癥，一直是 Agent 落地的核心障礙：受上下文窗口限制，跨會話記憶無法留存，導致服務連貫性差。PolarDB 通過 Mem0/MemOS 框架，為 AI Agent 構建了長期記憶層，徹底解決這一問題。

Mem0 框架的核心是記憶分層與多引擎聯(lián)動：將 Agent 記憶拆解為工作記憶（當前會話信息）、事實記憶（固定知識點）、情景記憶（歷史交互場景），通過原生集成的 PGVector 向量引擎與 Apache AGE 圖引擎，實現(xiàn)記憶的結(jié)構化存儲與高效檢索。

PolarDB Supabase 則讓 Agent 開發(fā)從基建工程變成搭積木。過去，開源 Supabase 雖能提供一站式后端能力，但部署時需協(xié)調(diào)十多個微服務，升級過程中非常容易出現(xiàn)兼容問題，運維成本極高。PolarDB Supabase 則采用托管應用層+數(shù)據(jù)庫核心的分離架構，將控制臺、API 網(wǎng)關、身份認證等組件全托管，開發(fā)者通過 PolarDB 控制臺就能統(tǒng)一配置，無需關心底層組件運維。

同時，PolarDB Supabase 中還加入了企業(yè)級增強設計：安全容器隔離防止信息泄露，內(nèi)置 Realtime 實時數(shù)據(jù)庫讓數(shù)據(jù)變更秒級推送至 Agent，RESTful API 省去重復的增刪改查編碼，甚至支持通過 SQL 語句直接調(diào)用阿里云百煉內(nèi)置大模型，大幅降低開發(fā)門檻。

如果說數(shù)據(jù)庫接入層面的大一統(tǒng)以及 Agent 能力設計，針對的還是傳統(tǒng)后端開發(fā)，那么 PolarDB 提出的模型算子化，則讓非技術人員也能玩轉(zhuǎn) AI 數(shù)據(jù)處理。模型算子化（Model as an Operator）的本質(zhì)是將 AI 能力封裝為數(shù)據(jù)庫原生算子，用戶無需掌握 Python 或 MLOps 技能，用熟悉的 SQL 語言就能完成模型調(diào)用，完成分類、回歸、聚類等常見需求。如此一來，數(shù)據(jù)無需遷出數(shù)據(jù)庫，所有處理與推理都能在庫內(nèi)完成，既避免數(shù)據(jù)傳輸中的安全風險，又減少延遲。

03

AI-Ready 的企業(yè)，

需要 AI-Ready 的數(shù)據(jù)

如果說 PolarDB 的進化，回答了 AI-Ready 數(shù)據(jù)庫如何建設的問題，那么企業(yè)如何管好數(shù)據(jù)、用好數(shù)據(jù)，也就是做好 AI-Ready 的數(shù)據(jù)，則是企業(yè)選好數(shù)據(jù)庫、做好 AI 轉(zhuǎn)型的前提。

而圍繞 Agentic Al 時代，如何用好數(shù)據(jù)，我們可以從道與術兩個方面出發(fā)去看。

道的層面，Gartner 發(fā)布的《Ready Your Data for AI》給出了答案：所謂AI 就緒的數(shù)據(jù)不是越多越好，而是要滿足「連接性（Connected）、持續(xù)性（Continuous）、精選性（Curated）、上下文相關性（Contextual）」四大特性。

這四道標準與 PolarDB 的技術設計高度契合：連接性要求打破數(shù)據(jù)孤島，對應 PolarDB 的湖庫一體與泛元數(shù)據(jù)管理；持續(xù)性要求數(shù)據(jù)實時更新流轉(zhuǎn)，依賴 Lakebase 的動態(tài)分層與 Realtime 能力；精選性要求數(shù)據(jù)與業(yè)務目標對齊，通過模型算子化讓數(shù)據(jù)處理貼合場景需求；上下文相關性則靠泛元數(shù)據(jù)與 Agent 記憶層實現(xiàn)，讓數(shù)據(jù)帶著場景信息供 AI 調(diào)用。

術的層面，不同行業(yè)的實踐給出了殊途同歸的解法。

在汽車行業(yè)，理想汽車依托 PolarDB 構建智駕元數(shù)據(jù)底座，查詢性能提升 3 倍、TCO 降低 60%，日推理調(diào)用量超百萬，支撐智能駕駛快速迭代，并極大簡化了企業(yè) AI 轉(zhuǎn)型的技術復雜度；在視頻社區(qū)，嗶哩嗶哩通過大模型+小模型協(xié)同框架，實現(xiàn)數(shù)據(jù)不出庫的智能營銷分析，為廣告主提供精準決策依據(jù)；在 AI 基座領域，MiniMax 用 PolarDB Limitless 架構解決千億級表查詢瓶頸，支撐 100+實例毫秒級響應。

當然，以上企業(yè)并非個例，截至目前，PolarDB 已服務超 2 萬客戶，部署規(guī)模超 300 萬核，覆蓋全球 86 個可用區(qū), 成為 AI 時代數(shù)據(jù)底座的主流選擇。

04

尾聲

在通往超級人工智能之路的這個過程中，不僅需要模型層面的進步，更需要解決不同格式、不同來源、不同用途的數(shù)據(jù)，打破 AI 落地最后一公里的核心桎梏。

而伴隨 PolarDB 這樣的數(shù)據(jù)庫從工具向 AI 基礎設施轉(zhuǎn)型：基于向量的多模態(tài)數(shù)據(jù)庫讓數(shù)據(jù)之間有了統(tǒng)一的語言，湖庫一體讓數(shù)據(jù)有了共同的存儲管理方式；模型算子化，讓數(shù)據(jù)能夠更低成本的被更多人所利用。

萬能的大模型+All-in-One 的數(shù)據(jù)庫+豐富的工具生態(tài)，讓構建 AI 應用的復雜度，變得前所未有的低門檻，AI-Ready 到 AI-Native 成為可能。

而 PolarDB 的探索，不僅給出了 AI 原生數(shù)據(jù)庫的標準，也讓無數(shù)企業(yè)拿到了通往 AI 時代最重要的的半張門票。

*頭圖來源：阿里云

本文為極客公園原創(chuàng)文章，轉(zhuǎn)載請聯(lián)系極客君微信 geekparkGO

極客一問

你如何看待PolarDB ？