MariaDB Enterprise Platform 2027 為 AI Agents 建立共享資料基礎
MariaDB 於 11 月 4 日推出 MariaDB Enterprise Platform 2027，讓企業 AI agents 更接近業務資料，而非額外增加另一套獨立的資料架構。此次發布將資料庫營運、分析、記憶及 AI 工具整合至同一個共享平台。其核心主張是，agents 應基於企業已在使用的資訊運作，並減少需要維護的連接。
這項公布挑戰了企業開發人員面對的一項架構選擇：擴展現有資料庫平台，還是在其周邊組裝專門服務。獨立系統讓團隊可自行挑選個別元件，但同時亦增加了同步資訊、執行存取規則，以及調查跨服務邊界故障的工作。
Oracle 提供了一個有用的參照，因為它同樣將 AI 功能置於營運業務資料旁邊。因此，MariaDB 正進入一場既有競爭：企業 AI 應該在哪裏運行。問題在於，哪種架構能讓買家加入 agents，同時維持日常應用程式的可靠性、資訊的即時性，以及清晰的責任歸屬。
MariaDB Enterprise Platform 2027 實際整合了甚麼
MariaDB 正在擴展其企業平台的涵蓋範圍，而非宣稱所有工作負載現時均在單一資料庫引擎內運行。
這項區別相當重要，因為「單一資料庫」可以描述幾種不同事物。它可能指一個儲存引擎、一個管理介面、一種商業合作關係，或一套一致的資訊存取方式。即使供應商以相近措辭描述，這些安排仍會帶來不同的營運影響。
根據該公司的平台公告，此次發布包括 Enterprise Server 12.3、Exa、GridGain、MaxScale、Enterprise Manager 及其 Kubernetes Operator。MariaDB 表示，該平台已正式推出，可部署於本地、雲端環境，並透過 MariaDB Cloud 使用。
這是一組圍繞資料庫基礎而組織的元件。買家應從這個層面理解整合主張。將元件納入獲支援的平台，可減少整合工作，但不會消除儲存、快取、查詢處理及管理之間的技術界線。
MariaDB 的平台架構明確區分了作為資料庫本身的 Enterprise Server，與更廣泛的 Enterprise Platform。周邊方案加入分析、記憶體內運算、可用性、管理及 AI 功能。原生向量搜尋會將內容的數值表示，與關聯式資訊一同儲存及搜尋。
這改變了採購討論的方向。資料庫評估通常由應用程式相容性、可靠性及查詢效能開始。MariaDB 現在希望該評估同時涵蓋 AI 應用程式在回答問題或跨工作階段延續工作前所需的服務。
對現有客戶而言，這提供了一條潛在的擴展路徑。團隊可先檢視鄰近現有資料庫的功能，再引入另一家供應商。對新客戶而言，該平台則成為一項更廣泛的架構承諾，值得在資料庫引擎以外加以評估。
此次發布亦在可用基礎設施與新興 AI 服務之間形成重要區別。MariaDB 的新聞稿稱，AI Retrieval 將於 11 月稍後時間在 MariaDB Cloud 進入公開預覽。其發布網誌則描述該預覽版已可使用。
這些說法未能確立一致的推出日期。截至 11 月 5 日，讀者應視檢索服務的推出時間在該公司各項資料中仍未明確。平台可用性不應被視為所有宣傳中的 AI 功能均具相同發布狀態的證據。
這種不確定性雖然狹窄，卻影響深遠。評估資料庫升級的團隊，與依賴託管檢索服務的團隊，可以採取不同做法。採購及工程團隊在將部署承諾附加於這次整體發布前，需要掌握元件層級的可用性情況。
壓力落在維護獨立 AI 資料服務的團隊身上
MariaDB 的整合主張將整合工作，而非模型選擇，置於企業 AI 採購決策的核心。
考慮一個說明性的客戶服務 agent 處理送貨爭議。它需要訂單狀態、運送記錄、退貨政策，以及自身調查的歷史。這些資訊各有不同用途，但客戶期望得到一個基於當前情況、前後一致的答案。
由獨立服務建立的架構必須連接這些用途。該 agent 可能從一個系統檢索政策文字，再從另一個系統要求訂單資訊。它亦需要一個地方記錄已完成的步驟，讓中斷的調查能夠續辦，而毋須從頭開始。
這些連接本身並非必然構成問題。專門服務可配合機構現有的技能或效能要求。困難在於，每一項連接都需要各自的權限、新鮮度規則、監察、復原程序及營運負責人。
政策文件可能已更新，但先前生成的答案仍被快取。訂單可能在 agent 檢索後有所變更。工作流程可能在完成外部操作後、記錄該操作完成前重新啟動。
這些是架構失效情境，並非有關 MariaDB 或其競爭對手的已報告故障。它們說明了整合為何具備商業吸引力。減少獨立管理的邊界，讓團隊有更少位置會令資訊與執行歷史逐漸偏離。
即時壓力落在應用程式架構師及平台工程團隊身上。當現有供應商提供相若功能時，他們必須解釋為何一項獨立服務值得承擔其營運開銷。這個解釋仍可能支持專門化，但單憑便利已成為較弱的理由。
資料庫管理員則從另一方向面對相應壓力。擴展受信任的資料庫平台會引入不熟悉的工作負載及存取模式。他們需要證據證明，支援 agents 不會令一般應用程式營運更難預測或復原。
保安團隊亦要承擔具體決定。共享平台承諾減少政策介面，但他們必須確定 agent 如何取得提出請求用戶的授權。只有在返回的資訊符合適用於該工作的權限時，整合才有用。
知識組織仍是這個問題的一部分。一個可搜尋的知識庫可協助團隊定位技術資料，但企業工作流程亦需要最新記錄及合適的存取權限。搜尋品質與營運正確性處理的是相關但不同的需要。
因此，這次發布促使兩個架構陣營都必須更加具體。偏好獨立服務的團隊需要交代協調成本；偏好整合的團隊則需要證明共享基礎設施能保留其應用程式所需的隔離性、彈性及問責性。
這比起計算產品頁面上出現多少項 AI 功能，是一場更有用的討論。實際比較在於，一次示範變成獲支援的業務應用程式後，還剩下多少工作。
Agent 記憶及檢索更接近營運記錄
其技術理據是縮短 agent 所知、已完成的工作，以及企業目前所記錄資訊之間的距離。
AI agent 是一種運用模型及工具追求任務的軟件，它需要的不只是相關文字。它還需要執行歷史，以及可靠地了解規管其下一步行動的資訊。MariaDB 所提出的架構，將這些要求拉近在一起。
該公司的agent 記憶架構將工作記憶與語義記憶分開；後者是按意思而非完全相同的字眼檢索的資訊。它把工作記憶置於高速快取中，並將語義記憶放在營運資料庫記錄旁邊。該頁面亦列出與現有 agent 開發框架的整合。
因此，MariaDB agent 記憶所處理的要求，與單純保留對話記錄不同。運行中的工作流程需要知道自己目前的位置。較長期的資訊有助後續互動恢復脈絡，而毋須重播每一次較早的交流。
回到送貨爭議的例子。工作記憶可追蹤 agent 在目前調查中已完成哪些檢查；較長期記憶則可保存已批准的解決方案，或與日後互動相關的客戶偏好。
這些是架構的說明性應用，而非已驗證的客戶部署。它們顯示儲存位置為何重要。暫時的執行細節與持久的業務脈絡，不應自動採用相同的保留、權限或復原行為。
檢索增加了另一項連接。MariaDB AI Retrieval 被描述為結合文件依據與即時營運資訊，並將自然語言請求轉換為唯讀 SQL。SQL 是用於向關聯式資料庫請求資訊的查詢語言。
唯讀界線具有意義，因為檢索資訊與變更業務記錄涉及不同的授權。能回答問題的系統，並不會自動具備退款、修改庫存或批准帳戶變更的資格。
開發人員仍須決定，建議答案會在何處轉化為獲授權的行動。他們亦需要區分從業務系統檢索的證據，與模型生成的結論。將證據放得更接近 agent，並不會消除這項區別。
快取在同一架構中引入另一項取捨。當新問題在語義上與先前問題相似時，語義快取會重用既有答案。MariaDB 表示其實作方式可減少重複的模型呼叫，但是否適用取決於所重用的資訊。
一般政策說明與帳戶結餘的即時性要求不同。措辭相似並不代表提出請求的用戶享有相同權限，或其底層記錄仍未變更。應用程式擁有人必須界定較早的答案在何時仍屬有效。
因此，MariaDB agent 記憶與檢索應屬同一架構討論的一部分，但不應被視為可互換的功能。記憶保存脈絡及進度；檢索為當前請求提供證據；快取則在重用仍然合適時避免重複工作。
該平台的吸引力來自圍繞營運資訊協調這些功能。其價值將取決於：當工作階段重新啟動、權限改變、記錄更新，以及應用程式在步驟之間失敗時，這種協調是否仍然易於理解。
統一平台在營運控制層面與專業化技術堆疊競爭
整合的最強理據，在於釐清整個應用程式的責任歸屬，而非消除每一項專業服務。
MariaDB 的發布詳情指出，Exa 現已可於本地部署環境正式使用，而 Enterprise Manager 可涵蓋資料庫、MaxScale 及 GridGain。內容亦提到共用存取控制，以及現已正式推出的 Bring Your Own Cloud 選項。這種部署安排會將託管服務的資料平面保留在客戶的雲端帳戶內。
這些功能分別處理營運控制的不同部分。共用管理可讓相關元件更容易觀察。部署選擇關乎基礎設施的運行位置。存取控制則關乎誰可擷取資訊。買家應按各項主張對應其相關需求作出評估。
採用同一供應商可令升級支援流程更直接。當一個應用程式橫跨多項由不同團隊支援的服務時，診斷問題可能演變為責任歸屬的爭論。整合平台可為買家提供更清晰的起點，但不代表每次故障都會變得簡單。
當企業需要獨立擴展、既有內部工具，或特定檢索實作方式時，專業化技術堆疊仍具優勢。服務邊界成熟的公司，可能發現替換成本高於繼續維護。整合必須證明其遷移成本值得付出。
因此，相關比較應在完整營運安排之間進行。整合選項可能簡化支援，卻同時增加對單一平台介面的依賴。專業化選項可能保留元件選擇權，但客戶仍須自行協調版本發布及故障復原。
Oracle 顯示，以資料庫為核心的做法並非 MariaDB 獨有。其文件所述的 AI vector search支援語意查詢，並將向量表徵與業務資料一同儲存。這提供了一個競爭例子，說明如何將面向 AI 的檢索功能帶入營運資料庫環境。
這並不代表其效能相同、部署選項等同，或功能完全對等。這些比較需要按工作負載提供的證據。較審慎的結論是，MariaDB 正在一個更廣泛的趨勢中競爭：將 AI 資料能力置於既有記錄附近。
對買家而言，這個趨勢改變了候選清單。正在評估檢索基礎設施的企業，可檢視其現有資料庫資產中已具備的能力。正在選擇資料庫的團隊，則可詢問該平台如何支援同時結合一般記錄查詢與語意搜尋的應用程式。
兩種決策都不應以消除獨立服務為前提。起點應是業務工作流程及其限制。當整合移除了原本需要由組織自行承擔的工作時，才會帶來價值。
相同推理亦適用於資料流動。較少需要分別維護的副本可簡化資料新鮮度管理，但應用程式仍須明確界定更新何時可見。產品描述不能取代這些預期。
MariaDB Enterprise Platform 2027 令營運控制成為資料庫採購中更重要的一環。其商業機會在於說服買家：更廣泛的平台可減輕整體協調負擔，同時保留應用程式所依賴的行為。
資料庫吞吐量並不能衡量完整代理工作流程
MariaDB 公布的效能提升支持的是資料庫效能主張，而非企業代理可更快完成工作的普遍結論。
該公司指出，McKnight Consulting Group 的測試顯示，Enterprise Server 12.3 相較 11.8 的峰值吞吐量高出 56%。其吞吐量基準測試附有披露資料，說明由 MariaDB 贊助，並在 Google Cloud 上進行測試。發布註腳列明採用 HammerDB TPROC-C，這是一種源自 TPC-C 的交易工作負載，而非官方 TPC-C 結果。
這些限定條件界定了讀者可作出的合理推論。資料庫在測試條件下能處理更多交易，為該工作負載提供了有用證據。然而，這並不描述代理在交付結果或完成已獲授權操作前所執行的每一項工作。
代理的總耗時可能包括檢索、模型生成、應用程式邏輯、外部服務及人工審批。提升資料庫吞吐量只改善當中的部分路徑。實際改善程度取決於應用程式的延遲有多少源自該處。
正在等待外部審批的工作流程，不會因資料庫可接收更多工作而按比例更快完成。以檢索為主的應用程式，可能與以模型生成為主的應用程式受惠方式不同。兩者都沒有削弱資料庫效能的重要性；但都可防止無根據的延伸推論。
峰值吞吐量亦有別於持續穩定的回應速度。買家需要了解，在執行高需求分析查詢時，一般請求會如何受到影響。他們亦需要知道，突發的代理活動會否影響已依賴該資料庫的應用程式。
這是整合最核心的審慎問題。合併工作負載可減少部分整合邊界，但同時提高平台內資源管理的重要性。共用基礎設施需要有方法，避免一種工作負載耗用另一種工作負載所需的資源。
故障行為同樣值得如速度般受到重視。代理可能正確恢復運作，卻回傳在重要更新前已檢索的資訊。反之，最新記錄可能可供使用，但工作流程未能判定哪些先前操作已完成。
這些可能性涉及跨元件的應用程式正確性。單靠交易基準測試無法解決。評估應將效能測量與復原行為，以及與業務任務相關的新鮮度保證連結起來。
快取令這種關聯尤其重要。重用答案可減少模型請求，但若底層資訊已改變，結果可能不可接受。成功的評估必須檢視快取何時拒絕重用，而不只是重用何時改善回應時間。
MariaDB AI Retrieval 的預覽版本定位存在模糊之處，也帶來發布管理方面的考量。買家需要識別哪些行為可在現有產品中驗證，哪些則依賴預覽服務。評估不應悄然混合這些不同成熟度層級。
MariaDB Enterprise Platform 2027 值得作為完整營運平台評估，但其證據應按主張分開看待。交易吞吐量、檢索相關性、記憶復原、權限執行及工作流程完成情況，分別回答不同問題。
三個訊號將顯示整合策略如何發展
下一批證據應確立功能可用性、混合工作負載下的行為，以及客戶營運可量度的改變。
第一個訊號是 MariaDB AI Retrieval 一致的可用性說法，並有可存取的文件及可用的預覽版本支持。11 月 18 日的發布網絡研討會，讓該公司有既定機會釐清服務狀態及部署範圍。
一致的說法將提升平台對計劃採用檢索型應用程式的團隊而言的即時實用性。若持續存在模糊之處，買家可放心納入近期項目的能力便會減少。問題很實際：工程團隊現時可評估及支援哪些功能？
文件亦應令檢索邊界容易理解。買家需要區分文件處理、即時資料庫查詢及模型生成回應。清晰分隔有助他們判斷資訊來源，以及工作流程中哪些部分必須由其自身應用程式管控。
第二個訊號是涵蓋並行業務及 AI 工作負載的效能證據。資料庫吞吐量仍然重要，但整合帶來的互動關係並非獨立測量可描述。證據應展示，當檢索、分析及代理記憶活動發生時，既有應用程式的表現如何。
具說服力的結果，會在展示有用額外容量的同時維持一般應用程式的回應能力。若結果顯示明顯相互干擾，則較有利於更具選擇性的整合策略。無論哪一種結果，都有助買家判斷哪些工作負載適合放在一起。
復原示範可為這些測量增添有用背景。恢復的工作流程應找回適當的執行狀態，並檢索現時獲授權的資訊。同時觀察這些行為，將支持整合改善營運而不只是令部署更方便的論點。
第三個訊號是客戶證據，說明採用後實際有何改變。只有知名公司名稱並不足夠。買家需要了解之前的架構、保留或淘汰的元件，以及轉移了哪些營運責任。
若證據顯示客戶減少了同步工作或簡化了事故診斷，將支持 MariaDB 的核心論點。若證據顯示客戶保留了大部分周邊服務，則意味該平台的角色較為狹窄。兩種結果都不應簡化為已安裝功能的數量。
這些訊號讓焦點維持在發布所提出的架構決策上。該公司提供了一種方法，將營運資料庫基礎延伸至更廣泛的企業代理環境。客戶必須判斷，這種延伸在多大程度上符合其既有系統及優先事項。
正在評估 MariaDB Enterprise Platform 2027 的團隊，應從一個橫跨記錄、文件及執行歷史的業務工作流程開始。確定誰可存取每個來源、更新必須多快顯示，以及中斷工作階段後哪些內容必須保留。以相同成功條件，將整合方法與現時營運的服務作比較。記錄所移除的整合工作、引入的新依賴關係，以及仍由團隊承擔的責任。在根據基準測試或功能示範作延伸推論前，要求提供與這些條件相關的證據。有用的決策是：此平台能否令你選擇的工作流程，在使用最新資訊及具備清晰權限的情況下更容易營運。整合實際上可從你的應用程式移除哪些負擔？
