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 ？