文｜產業(yè)家 斗斗
編輯 | 皮爺
數據庫的角色正在被徹底重寫：不再只是數據倉庫、事務賬本、分析引擎，而是智能系統(tǒng)中真正可信的核心。AI成為組織大腦，數據庫就是數據調度的中樞——誰掌握數據流，誰就掌握智能流。
數據庫，這個長期“藏在后臺”的基礎設施，正被AI時代推向臺前。
客服想更精準地回答用戶問題，推薦系統(tǒng)希望更快做出響應，風控模型則需要更實時地識別風險——這些智能能力的背后，離不開數據庫提供持續(xù)、結構化、具備上下文的數據支撐。
“以前數據庫是倉庫，現在更像是中樞?！盌atabend CEO 張雁飛這樣對產業(yè)家形容。
這一角色轉變，正重新定義數據庫在企業(yè)系統(tǒng)中的位置：它不僅要存數據，還要參與推理、支撐決策、響應模型調用，成為智能系統(tǒng)的“實時大腦”。
與此同時，問題也隨之而來。
“原先的權限系統(tǒng)正在失效?！蹦成鲜衅髽I(yè)數據安全產品部總經理陳宇耀對產業(yè)家直言。
一個事實是，性能跟不上、權限不好管、安全邊界模糊……尤其在AI大量接入后，傳統(tǒng)數據庫架構和管理方式正面臨重壓。
數據庫，正在經歷一次深層的升級。
這一輪變化，對廠商、客戶、產品、安全體系，都是一次重新洗牌。
一、AI，讓數據庫正在“走向前臺”
“過去數據庫偏向后臺靜態(tài)數據倉庫，而今天，它更像一個前臺實時系統(tǒng)?！睆堁泔w告訴產業(yè)家，“數據庫，終于有新故事了?！?/p>
過去，數據庫的核心職責是存儲和查詢，主要被用于記錄訂單、交易、庫存等結構化數據。但隨著AI模型進入客服、搜索、推薦、分析等業(yè)務流程，數據庫的角色正在發(fā)生變化。
越來越多企業(yè)意識到，要讓AI系統(tǒng)“理解業(yè)務”，必須讓它獲取實時的、結構化的數據上下文。而這些數據，大多存放在數據庫中。數據庫逐漸成為AI模型背后的信息源，也成為支撐企業(yè)自動化流程的關鍵基礎設施。
在搜索增強生成（RAG）、Agent系統(tǒng)、實時推薦等場景中，數據庫被用于：存儲模型調用所需的上下文信息，如用戶歷史、商品屬性、產品知識；支持向量檢索，用于語義搜索、相似內容匹配；記錄AI Agent的狀態(tài)和決策流程，確保自動化行為可追蹤、可回溯。
數據庫的調用方式也在變化。
以往是人操作系統(tǒng)時觸發(fā)數據庫查詢，現在是模型或Agent自動生成請求。這些請求頻率高、鏈路復雜、語義模糊，對數據庫的性能和響應能力提出更高要求。
多位數據庫從業(yè)者跟產業(yè)家提到，客戶正在要求數據庫“不僅能存數據，還要能理解語義”。這意味著數據庫需要支持更豐富的索引結構、更靈活的數據格式，以及與AI系統(tǒng)之間更高效的接口。
“一個客戶將數據庫接入AI客服系統(tǒng)，每一次用戶提問，模型都需要查詢產品信息、用戶偏好、訂單狀態(tài)等多個字段。過去一分鐘調用幾次數據庫就足夠，現在幾秒鐘可能就要處理上百次請求?！睆堁泔w告訴產業(yè)家。
除了性能壓力，客戶也希望數據庫能兼容多種數據類型。
一些新應用需要同時處理結構化數據（如用戶表）、非結構化數據（如文本記錄）、向量數據（如語義嵌入）。數據庫產品也開始集成更多原本由搜索引擎、緩存系統(tǒng)、特征平臺承擔的功能。
這種變化不只是企業(yè)需求上的提升，也帶動數據庫產品形態(tài)的演進。傳統(tǒng)數據庫的設計假設是“人操作系統(tǒng)”，現在則必須適應“AI操作系統(tǒng)”的需求。
一些主流數據庫產品已開始做出回應。
例如，PostgreSQL 社區(qū)涌現出多個兼容 LLM 的擴展模塊；Databend 等云原生數倉則在底層集成向量與結構化數據的混合檢索能力。
尤其是 Databend，其優(yōu)勢在新一輪洗牌中愈發(fā)凸顯。
張雁飛告訴產業(yè)家：“我們并不是在給傳統(tǒng)數據庫加AI插件，而是在為AI生態(tài)造數據庫?！?/p>
在研發(fā)一線，這種變化也體現在團隊討論方式的轉變。
過去數據庫團隊主要關注寫入性能、查詢優(yōu)化、事務一致性，現在越來越多話題圍繞“模型能不能讀得快、Agent調得穩(wěn)、上下文能否持續(xù)更新”。
總的來說，數據庫的“用戶”已經從人，變成了模型和Agent。
這是一個看似細微、實則根本的變化。
它不僅改變了數據庫的訪問方式，也意味著數據庫必須承擔更多“推理輔助”和“協(xié)同管理”的責任。
二、技術轉型的挑戰(zhàn)和安全隱憂，集體爆發(fā)
數據庫“走向前臺”的轉變，不只是性能優(yōu)化的問題，更是一場架構重構和安全重塑的系統(tǒng)性挑戰(zhàn)。
在AI時代，數據庫廠商面臨的核心問題不再是單點能力的提升，而是如何適應更復雜、更動態(tài)的智能應用需求。
首先，數據庫形態(tài)正在發(fā)生根本性變化。過去，系統(tǒng)按“專一能力”劃分——做事務處理就專注OLTP，做分析就服務于數據倉庫。
但今天的企業(yè)，越來越傾向于“一庫多能”。既要結構化查詢，也要圖譜檢索、向量搜索、流式處理，甚至希望能原生支持Prompt編排與自然語言接口。
“客戶經常問我們，能不能一個數據庫同時做推薦、搜索，還能配合Copilot?！?張雁飛說，“這不是簡單的功能疊加，而是要求我們從內核設計上支持多模態(tài)融合?！?/p>
為了支撐AI系統(tǒng)復雜的調用鏈，數據庫廠商正在底層架構上做出調整。例如，在索引體系中引入倒排索引、向量索引和混合檢索模塊；在查詢引擎中兼容SQL與自然語言解析；在執(zhí)行邏輯上犧牲部分一致性，以保證實時響應。
張雁飛表示：“客戶不關心數據庫叫什么名字，他們關心的是，這個數據庫能不能支撐AI系統(tǒng)實時運行。”
但這讓一些問題逐漸顯現。
一個事實是，盡管國內數據庫廠商在OLTP與OLAP領域已有突破，但面對AI原生場景，依然存在架構短板。向量檢索、多模融合、Agent友好型接口等新需求，對廠商的系統(tǒng)設計靈活性和技術積累提出更高要求。
“我們一開始就以Serverless和云原生為基礎，這才讓我們有機會在底層集成向量和圖譜等能力?！睆堁泔w坦言，“如果從關系型出發(fā)，中途再轉，幾乎不可能。”
與此同時，數據庫的安全模型也面臨前所未有的挑戰(zhàn)。
過去，安全重點是“防人出錯”——通過權限配置、訪問控制、加密等手段保護數據。但如今，數據庫頻繁被AI模型與Agent程序調用，這些系統(tǒng)具備“類人”的主動性，傳統(tǒng)的權限體系正在失效。
“以前權限是基于角色或崗位來配置的。但現在，一個Agent可能同時代表多個角色，每秒發(fā)起成百上千次請求，我們根本不知道它在查什么?！标愑钜珜Ξa業(yè)家說。
權限失控已不再是預警，而是現實問題。
許多企業(yè)在部署AI系統(tǒng)時，忽略了對Agent行為的審計和限制。例如，在RAG系統(tǒng)中，若缺乏權限過濾，用戶可能通過Prompt調取數據庫中的敏感信息。
“問題不在模型本身，而在于數據庫缺乏識別‘訪問者身份’與‘訪問動機’的能力?！标愑钜赋觥?/p>
更值得警惕的是，向量數據庫還引入了新的安全風險：攻擊者可能反推訓練語料，或通過注入“污染數據”操控檢索結果，進而影響模型輸出。
“我們已經看到一些攻擊案例：在知識庫中混入歪曲內容，讓模型輸出出現偏差。”陳宇耀告訴產業(yè)家，“傳統(tǒng)的數據防泄漏系統(tǒng)在這里幾乎無效，因為它無法識別語義層的攻擊。”
這也意味著，數據庫安全的定義正在被重寫。
過去關注的是“存儲安全”，而AI時代，更需要關注調用鏈路的可見性、訪問行為的可解釋性，以及上下文權限的動態(tài)調整能力。
“數據不再固定在一個庫里，它在多個Agent之間流動?！标愑钜偨Y道，“未來需要一種新型安全組件，它不再圍繞‘系統(tǒng)邊界’，而是圍繞‘數據本體’建立權限策略——權限要隨數據走?！?/p>
三、數據庫+AI怎么走？走到哪了？
面對AI引發(fā)的結構重構與安全沖擊，企業(yè)開始嘗試通過“補能力、調權限、改架構”的方式應對，但這些嘗試大多仍處在探索初期。
第一步嘗試，集中在產品能力的擴展上。
企業(yè)希望數據庫能原生支持文本、圖像、向量等多模數據處理，減少對中間件的依賴?！翱蛻粼絹碓较Ｍ粋€系統(tǒng)處理多種數據結構，而不是東拼西湊?！睆堁泔w直言。
然而，從實際來看，這一能力尚未標準化。
一些系統(tǒng)僅支持簡單的向量相似度計算，難以勝任復雜語義檢索；也有廠商雖引入向量模塊，但與主查詢引擎耦合度低，存在性能瓶頸與一致性問題?！皵祿?向量”更多是“接上了”，距離“融合好用”仍有距離。
與此同時，“上下文管理”機制也尚不成熟。當前多依賴緩存或臨時表來提供上下文信息，缺乏一套高效統(tǒng)一的調用模型。多位業(yè)內人士坦言，目前尚無數據庫在AI上下文支持方面形成行業(yè)共識。
第二類應對，聚焦于安全模型的重構。
AI系統(tǒng)頻繁調用數據庫，但原有權限設計與審計機制并未同步升級。一些企業(yè)嘗試通過Agent側的訪問白名單、上下文窗口等方式，限制其可訪問字段范圍。
“以前權限是‘人對人’，現在得變成‘Agent對字段’。但很多企業(yè)甚至搞不清自己用了多少數據庫調用、有哪些Agent在跑?！标愑钜f道。
雖然部分企業(yè)已引入運行時加密、動態(tài)權限調整、審計網關等機制，但這些組件多為外掛，無法與數據庫主系統(tǒng)統(tǒng)一策略、協(xié)同運行，反而增加了系統(tǒng)復雜度。
更大的問題在于，大多數數據庫并不具備原生的“身份鏈路”和“行為路徑”可視能力。AI調用鏈路層層嵌套、日志分散，企業(yè)即使發(fā)現風險事件，也難以準確追溯全過程。
第三類嘗試，則是在整體架構上做取舍與隔離。
部分企業(yè)選擇將敏感數據保留在本地，僅在云端運行非核心AI任務；也有企業(yè)部署數據庫一體機，封閉Agent接口以強化管控。
“一家金融客戶把Agent的訪問范圍限制在每日自動銷毀的只讀表內，雖然安全，但代價是靈活性和實時性大打折扣?！睆堁泔w說。
當前，混合部署與權限隔離是相對可行的務實策略，但也帶來數據同步壓力、接口維護成本高、系統(tǒng)響應延遲等一系列副作用。而要真正實現“安全與效率兼顧”，企業(yè)還需在數據庫引擎層構建具備策略調度能力的原生機制，目前這一能力尚屬空白。
更現實的問題是，即使某些數據庫在功能上實現替代，仍可能在復雜SQL優(yōu)化、多模協(xié)同、Agent狀態(tài)一致性等細節(jié)上出現不穩(wěn)定。這種技術缺口導致AI應用在測試階段表現良好，但一旦接入真實業(yè)務流量，常常暴露出查詢卡頓、語義漂移、權限錯配等問題。
“AI改變了數據庫的角色，但技術體系還沒跟上?！币晃恢圃炱髽I(yè)CIO對產業(yè)家直言，公司目前采用的是“加一層、補一段、設幾個限”的方案。
他還說：“這聽起來安全，其實只是感覺安全?！?/p>
四、未來走向，誰能造出 AI 時代的“數據引擎”？
目前，業(yè)界普遍認為，AI時代的數據庫將沿著三個方向持續(xù)演進：一體化、智能化、安全內生化。
具體來看，首先是數據庫將走向架構一體化。
過去，企業(yè)往往需要部署多個數據庫來分別處理結構化、日志、向量或圖譜數據。這不僅造成架構冗余，還帶來數據同步、權限治理和審計合規(guī)的額外負擔。
“未來的數據庫，應該能統(tǒng)一處理結構化、文檔、圖數據和向量數據，并提供一致的查詢接口與權限體系?！盌atabend CEO 張雁飛表示，“我們希望把過去五個工具才能完成的任務，壓縮成一個產品來實現?！?/p>
然而，這種一體化仍面臨技術挑戰(zhàn)。
不同數據類型在存儲格式、索引結構、查詢語義上差異顯著，要在同一引擎內高效支持并不容易。目前多數所謂的“融合型數據庫”，仍是關系型架構上外掛功能模塊，缺乏真正的底層融合。
其次，數據庫將更加“懂AI”，也將“用AI”。
AI正倒逼數據庫“前臺化”，同時也成為其自身能力升級的關鍵工具。目前，已有廠商借助大模型生成SQL、構造測試用例、優(yōu)化查詢計劃，大幅提升開發(fā)與運維效率。
“我們已經用AI自動生成上萬組查詢語句，覆蓋各種業(yè)務場景，這在人力時代幾乎不可能?！睆堁泔w指出，未來數據庫優(yōu)化器的演進也將依賴大模型，“AI會成為數據庫研發(fā)流程中的標配工具?！?/p>
但“懂AI”還不夠，數據庫必須“適配AI”，解決上下文管理、Agent狀態(tài)維護、調用路徑壓縮等新場景問題。目前，行業(yè)尚缺乏統(tǒng)一的接口規(guī)范和調用語義標準，數據庫之間的協(xié)同能力仍有壁壘。
第三，安全能力必須內嵌進數據庫系統(tǒng)本身。
AI應用對數據訪問模式的改變，使“外掛式安全”逐漸失效。頻繁自動化調用、行為不透明、權限動態(tài)變化，要求數據庫具備原生的權限管理、行為審計、訪問透明和運行時加密等能力。
“權限系統(tǒng)不能只是配置文件或外置引擎，它必須嵌入數據庫核心邏輯?！标愑钜赋?。真正“安全內生”的數據庫，應深度融合身份體系、行為模型與策略引擎，為AI調用提供全過程可控的信任機制。
目前，僅有少數產品嘗試將權限、調用路徑與敏感字段識別“綁定”在引擎層，大多數仍停留在網關封堵、合規(guī)對接階段，距“安全即設計”還有不小差距。
誰能率先完成這三重轉型，有望成為AI時代新的基礎設施提供者。
值得注意的是，這場變革也為新興玩家提供了窗口。傳統(tǒng)數據庫廠商架構包袱沉重、演進緩慢，而一些新項目則從AI場景出發(fā)，繞過舊范式，直接構建面向Agent、向量與上下文的底層邏輯。
“AI對數據庫的重構，不是插件升級或功能擴展，而是理念轉變——從存儲轉向協(xié)同，從記錄轉向參與。”張雁飛強調。
從這個視角看，數據庫的角色也在徹底重寫：不再只是數據倉庫、事務賬本、分析引擎，而是智能系統(tǒng)中真正可信的核心。AI成為組織大腦，數據庫就是數據調度的中樞——誰掌握數據流，誰就掌握智能流。
當然，這一進化仍在進行中。一體化架構仍在調試，智能能力受限于應用場景，安全機制尚未標準化落地。要真正成為AI系統(tǒng)的“實時引擎”，數據庫還需穿越長坡厚雪。