Michael Stonebraker 如何從 Ingres、Postgres 到專用資料庫，塑造 AI 資料底座？

AI 系統需要向量檢索、特徵資料、事件串流、分析倉儲與交易狀態，但這些工作負載不會因為都叫「資料」就適合同一種引擎。Michael Stonebraker 長達半世紀的研究主線，正是拒絕把資料庫視為單一產品類別：先用 Ingres 與 Postgres 改變關聯式系統，再以 C-Store、H-Store、SciDB、Data Civilizer 等專用架構拆解不同負載。今天的 AI 資料平台之所以能談分層、可擴充與專用執行，很大一部分源自這條路線。

本次增量查證：MIT News將 Stonebraker 的 Ingres、Postgres、C-Store、H-Store 與 SciDB 放在資料庫管理系統的長期演化裡，也提醒其工作同時連到研究與企業化。本文對 AI 資料底座的延伸，是依工作負載做的架構分析，不等於 Stonebraker 直接提出今天所有向量資料庫或生成式 AI 系統。

先講結論：從 Ingres、Postgres、C-Store 與 H-Store，到 SciDB、Data Civilizer 與 DBOS，理解 Michael Stonebraker 如何用工作負載重畫 AI 資料系統邊界。

這篇文章在回答什麼？ 本文以Michael Stonebraker 如何從 Ingres、Postgres 到專用資料庫，塑造 AI 資料底座？為主軸，整理背景、關鍵概念與讀者最需要先掌握的脈絡。

核心重點是什麼？ 核心重點是把Michael Stonebraker 如何從 Ingres、Postgres 到專用資料庫，塑造 AI 資料底座？放回時間、人物、作品或產業背景，不只記住單一結論。

為什麼值得關注？ 它連結具體內容與更大的文化、社會或技術脈絡，能幫助讀者理解影響與限制。

文章提供哪些證據？ 文章整理主要人物或元素、發展線索、重要轉折與可回查的資料方向。

適合誰閱讀？ 適合想快速理解Michael Stonebraker 如何從 Ingres、Postgres 到專用資料庫，塑造 AI 資料底座？、查找背景，或希望延伸研究的讀者。

閱讀時要先注意什麼？ 先確認主題的定義、時間點與關鍵名詞，再對照文章中的證據與不同觀點。

它和其他主題如何連結？ 文中把Michael Stonebraker 如何從 Ingres、Postgres 到專用資料庫，塑造 AI 資料底座？與相關人物、作品、類型或時代背景串起來，呈現它在整體脈絡中的位置。

可以得到什麼結論？ 結論不是孤立答案；Michael Stonebraker 如何從 Ingres、Postgres 到專用資料庫，塑造 AI 資料底座？也反映內容選擇、敘事方法與文化語境的交互作用。

想繼續了解可以怎麼做？ 建議讀完全文後，延伸查閱文中提到的作品、人物、事件與官方資料，逐項核對細節。

AI 系統需要向量檢索、特徵資料、事件串流、分析倉儲與交易狀態，但這些工作負載不會因為都叫「資料」就適合同一種引擎。Michael Stonebraker 長達半世紀的研究主線，正是拒絕把資料庫視為單一產品類別：先用 Ingres 與 Postgres 改變關聯式系統，再以 C-Store、H-Store、SciDB、Data Civilizer 等專用架構拆解不同負載。今天的 AI 資料平台之所以能談分層、可擴充與專用執行，很大一部分源自這條路線。

實體索引｜資料庫系統與 AI 資料底座實體

• 人物、系統與資料庫：Michael Stonebraker 如何從 Ingres、Postgres 到專用資料庫，塑造 AI 資料底座？；核對 Michael Stonebraker、Ingres、Postgres、專用資料庫、查詢／儲存架構與 AI 資料場景。
• 原文錨點：AI 系統需要向量檢索、特徵資料、事件串流、分析倉儲與交易狀態，但這些工作負載不會因為都叫「資料」就適合同一種引擎。Michael Stonebraker 長達半世紀的研究主線，正是拒絕把資料庫視為單一產品類別：先用 Ingres 與 Postgres 改變關聯式系統，再以 C-Store、H-Store、SciDB、Data Civilizer 等專用架構拆解不同負載。今天的 AI 資料平台之所以能談分層、可擴充與專用執行，很大一部分源自這條路線。 本次增量查證： MIT
• 系統脈絡：把關聯資料、擴充、專用工作負載、分析、資料治理與 AI 管線連回資料底座設計。
• 編輯界線：區分開源專案、商用產品、系統架構與作者推論。

他的遺產不是一套資料庫，而是一種造系統的方法

Stonebraker 經常被用 PostgreSQL 之父或連續創業家概括，但這些標籤都太窄。他的工作模式是觀察既有 DBMS 在新負載上的根本限制，提出不同架構，建立可運行原型，再透過開源社群或公司把概念帶進真實部署。研究、工程與商業化不是三段分離履歷，而是一個反覆循環：用現場問題校正學術假設，再讓新系統接受規模、可靠度與維運的壓力。 MIT News 的圖靈獎報導指出，他在資料庫概念與系統實作上都留下基礎性成果，並創辦多家公司將技術商業化。這種「研究系統必須被使用」的態度，後來成為資料基礎設施領域的重要傳統：論文中的漂亮架構若無法處理故障、升級、資料偏斜與操作成本，就還沒有完成。

Ingres：讓關聯模型從理論走向可運行系統

一九七〇年代的關聯模型仍在證明自己能否成為實用資料管理方法。Stonebraker 與 Berkeley 團隊建立 Ingres，讓宣告式查詢、關聯運算與成本導向執行成為可以被部署與延伸的系統。它的影響不只在一個產品家族，而在於證明資料管理可以把「使用者描述要什麼」與「引擎決定怎麼做」分開。 這個分離至今仍是 AI 資料基礎設施的核心。上層可以提出特徵聚合、向量條件、語意查詢或資料品質規則，下層則依統計、索引、分區與硬體選擇執行策略。沒有這層抽象，每個 AI 應用都得自行處理儲存布局與查詢程序，系統無法共享優化，也難以建立治理邊界。

Postgres：把資料類型與擴充性放進核心

Ingres 之後，Stonebraker 沒有只替既有關聯系統加速，而是用 POSTGRES 探索更豐富的資料型態、規則與可擴充能力。PostgreSQL 官方歷史記錄，Berkeley POSTGRES 專案在一九八六年開始實作，之後經 Postgres95 加入 SQL，再演化成今日 PostgreSQL。這條歷史提醒我們，現代 PostgreSQL 並非單次設計完成，而是研究原型、社群維護與工程重寫長期疊加的成果。 對 AI 團隊而言，Postgres 的啟示不只是「也能裝向量 extension」。更重要的是擴充機制讓資料型別、函式、索引方法與查詢能力可以加入同一套交易、權限、備份與觀測環境。這降低新資料能力的導入門檻，但也帶來責任：extension 的正確性、升級相容、索引成本與查詢計畫仍要實測，不能因為介面統一就假設工作負載相同。

從通用系統轉向「一種架構不會適合所有負載」

Stonebraker 後期最有影響力的主張，是通用資料庫為了涵蓋所有情境而背負大量折衷。交易、分析、串流、科學陣列與文字整合在存取模式、延遲目標、更新比例與資料布局上不同；若硬塞進同一種 row store、同一套並行控制與同一執行器，系統可能在每種情境都只做到尚可。 這不是鼓勵企業無限制採購資料庫。專用系統會增加資料複製、介面、觀測、權限與人才成本。Stonebraker 路線真正要求的是先辨識工作負載，再決定哪些差異值得用專用架構換取巨大效益。AI 平台的向量庫、feature store、lakehouse 與線上交易層也應接受同一檢查：需求是本質不同，還是只是產品分類創造出的新孤島？

C-Store 與列式分析：只讀需要的欄，而不是搬整列

資料倉儲常在少數欄位上掃描大量資料，和逐筆更新的交易負載不同。C-Store 把欄位分開儲存，配合排序、壓縮與向量化處理，讓分析查詢減少 I/O 並提高 CPU 效率。MIT CSAIL 的 C-Store 查詢執行摘要說明 row store 偏向一次寫入完整紀錄，而 column store 更適合大量讀取與臨時分析。 這條研究影響了 Vertica，也預示今日 Parquet、warehouse 與 lakehouse 常見的列式布局。AI 特徵建置、訓練資料掃描與離線評估通常只使用寬表中的部分欄位，列式壓縮能直接降低成本。然而線上代理若需要毫秒級更新與單筆查找，完全相同的布局未必合適；分離離線分析與線上服務，正是專用架構思考的延伸。

H-Store 與 VoltDB：為記憶體交易重新設計

當資料可留在記憶體，傳統為慢速磁碟設計的 buffer pool、鎖與背景寫回機制可能變成負擔。H-Store 探索以分區、預存程序與較簡化的執行模型處理高吞吐交易，後續形成 VoltDB 的商業路線。它展現 Stonebraker 常用的方法：不是在舊架構上逐層加快，而是先問硬體條件改變後，哪些歷史機制已不再合理。 AI agent 逐步介入付款、庫存、客服與工作流時，可靠交易狀態比模型輸出速度更重要。代理可以提出動作，但資料層必須處理併發、冪等、排序、失敗恢復與稽核。H-Store 的價值不在於每個 agent 都該採用同一引擎，而在於提醒平台設計者：線上決策是一種交易工作負載，不能用離線向量索引或分析表取代一致性控制。

SciDB：陣列資料不是勉強攤平的關聯表

科學與感測資料常以多維陣列呈現，操作也圍繞切片、鄰域、座標與線性代數。SciDB 以陣列模型和分散式運算服務這類需求，反映「資料模型應貼近問題結構」的原則。影像、氣候、天文、基因與機器學習張量如果全被迫拆成普通 row，查詢意圖與物理布局之間會產生大量轉換成本。 今天的張量執行器與物件儲存並不等於 SciDB 的直接延續，但問題仍相同：要在哪一層保存形狀、區塊、座標與版本資訊？若訓練管線只看到無語意的檔案集合，資料重現與局部存取會變得昂貴。專用資料模型的價值，是把常用操作變成一等公民，同時讓系統能針對硬體與分區進行優化。

Data Civilizer：AI 的瓶頸往往在模型之前

企業資料科學最大的時間成本，常不是調整模型，而是找到資料、理解關係、清洗、轉換與合併實體。MIT CSAIL 的 Data Civilizer 專案頁把資料探索、view construction、清理、轉換與 golden record 建立放在端到端流程中。這個方向把注意力從單次查詢效能轉向資料準備的整體摩擦。 MIT DSAIL 的第一方說明進一步連結結構化與非結構化資料、entity resolution、人機協作與機器學習管線。對今天的 RAG 與企業 agent 而言，這些問題非常直接：檢索系統若無法識別同一客戶的多個紀錄、文件版本或欄位語意，增加 embedding 維度也不會自動產生可信答案。

從資料庫到 DBOS：把狀態管理推到更大範圍

Stonebraker 近年的 DBOS 構想延續資料庫中心觀點：如果現代應用大量邏輯都圍繞狀態與事件，作業系統與雲端執行是否也能以可查詢、可回復的資料狀態為核心？MIT CSAIL 的 DBOS 活動資料把這項工作放在他從 C-Store、H-Store、SciDB 到資料整合系統的連續脈絡中。 這對 agent infrastructure 特別有吸引力，因為代理流程需要 durable execution、事件歷史、重試、補償與可觀測狀態。但概念吸引力不等於生產驗證。團隊仍應用故障注入、重播一致性、效能隔離與操作成熟度來評估，而不是因「database-oriented」就假設自動取得資料庫級可靠度。

開源與商業化形成雙向壓力測試

Postgres 的程式碼與概念透過公開散布形成長期社群；Ingres、Illustra、Vertica、VoltDB、Tamr 等路線則把研究帶進企業市場。CSAIL Alliances 對 Stonebraker 的訪談介紹列出多個系統與衍生公司，顯示他並不把商業化視為學術工作的附註。 這種雙向路徑讓設計受到兩種不同檢驗。開源社群要求介面、可移植性與長期維護；商業客戶要求服務、升級、責任與成本。AI 基礎設施新創若只在 benchmark 中展示吞吐，或只靠市場需求堆疊功能，都容易忽略另一側。好的研究系統需要真實使用者，好的產品也需要清楚的架構假設。

Stonebraker 方法的三個設計原則

第一，先用工作負載說話。讀多寫少、短交易、陣列計算與資料清理必須分別量測，不能以「大資料」或「AI-ready」代替需求。第二，硬體改變時重新檢查架構。記憶體、網路、NVMe、GPU 與物件儲存會改變成本排序，歷史最佳實務可能成為新瓶頸。第三，建立完整系統驗證論點。單一演算法的提升若被資料移動、協調或維運成本吃掉，就沒有形成平台價值。 這三點也提供採購 AI 資料產品的實用框架：要求供應商說明目標負載、失效模式、資料一致性、硬體假設與可觀測性；在自己的資料分布上測試，而不是只看標準 demo；最後計算跨系統複製、治理與 on-call 的總成本。專用化只有在收益大於整合成本時才成立。

不能把他的觀點簡化成反對通用資料庫

Stonebraker 對 one-size-fits-all 的批判，並不表示每個團隊都應把架構拆成十套資料庫。小型團隊常從成熟通用系統獲得更好的可靠度與人才可得性。專用引擎的合理門檻，是工作負載差異已造成可量測瓶頸，而且團隊有能力處理資料同步、災難復原、權限與版本生命週期。 同樣地，PostgreSQL 的成功也不是 Stonebraker 一人完成。它建立在 Berkeley 團隊、Postgres95 開發者與數十年全球社群之上。人物介紹文章應辨識架構領導與早期貢獻，但不能抹去共同作者和維護者。把英雄故事改成系統演化史，反而更能看懂技術為何能存活。

為何 Michael Stonebraker 值得列入 AI 基礎設施人物介紹

從關聯式資料庫、可擴充物件關聯模型、列式倉儲、記憶體交易、科學陣列到資料整合，Stonebraker 一再把新工作負載轉成可驗證的系統問題。他的影響不只是一串產品名稱，而是建立了資料領域的進攻節奏：挑戰既有假設、做出完整原型、讓真實使用者施壓，再把教訓帶進下一代架構。 AI 產業很容易被模型能力吸走注意力，但模型始終運行在資料狀態、交易邊界、查詢優化與治理流程之上。當團隊開始討論向量與 SQL 如何共存、線上與離線如何分層、metadata 如何被代理使用時，其實仍在回答 Stonebraker 長期追問的問題：資料的形狀和負載已經變了，系統架構是否也真的跟著改變？

延伸閱讀

若想把資料庫系統史連到今日分析資料平台，可以接著閱讀Jordan Tigani與BigQuery、MotherDuck：分析資料庫的下一層，對照陣列資料、查詢引擎、成本與AI工作流。

官方與第一方資料

• MIT News：Michael Stonebraker 獲圖靈獎
• MIT CSAIL：Michael Stonebraker 人物與研究專案
• PostgreSQL 官方文件：POSTGRES 與 PostgreSQL 歷史
• MIT CSAIL：C-Store 查詢執行研究摘要
• MIT CSAIL：Data Civilizer
• CSAIL Alliances：Michael Stonebraker 訪談與系統脈絡

資料庫選型必須從工作負載開始

Michael Stonebraker 最持久的貢獻，是把資料庫從單一產品類別重新拆成一組工作負載問題。交易、分析、串流、科學陣列與資料清理在更新比例、延遲、資料布局和一致性要求上不同；若所有需求都被迫使用同一種執行器，團隊可能在每一項都只得到尚可的結果。MIT News 對其研究的回顧，正是以這種長期系統觀連結 Ingres、Postgres 與後續專用引擎。 這不等於每家公司都應部署多套資料庫。專用化只有在工作負載差異造成可量測瓶頸、且團隊能承擔同步、備份、權限與人才成本時才合理。第一步應先以真實資料分布量測讀寫、尾端延遲和故障恢復，再決定是否值得增加系統邊界。

PostgreSQL 的成功來自長期演化

PostgreSQL 官方歷史說明 Berkeley POSTGRES 在 1980 年代開始實作，後來經 Postgres95 加入 SQL，才逐步成為今日的 PostgreSQL。這條時間線很重要：一個成熟資料庫不是單次設計完成，而是研究原型、社群維護、介面相容與長期修補共同累積。AI 團隊使用向量索引或資料庫擴充時，也必須同時檢查升級路徑、索引成本、權限與備份，而不能只看 demo 的查詢速度。 MIT CSAIL 的 人物與研究頁及 PostgreSQL 的官方歷史文件可用來交叉確認人物角色、專案名稱與演化順序。

從列式分析到資料整合

C-Store 將欄位分開儲存，讓分析查詢只搬運真正需要的欄位，這種思路後來在列式檔案與資料倉儲中普遍可見。對訓練資料和離線評估而言，壓縮與向量化可以降低 I/O；但線上代理需要單筆查找與快速更新時，另一種布局可能更合適。Data Civilizer 則把問題推進資料發現、清理、實體解析和可追溯轉換，指出模型之前的資料準備常才是瓶頸。 實務上可以用三個問題驗證專用系統：它是否改善端到端任務而非單一查詢？資料同步與治理成本是否被量化？當資料量或模式改變時，是否有可回退方案？這些問題比產品標籤更能判斷架構是否適合。 若想把資料庫專用化放回 AI 硬體與工作負載的系統脈絡，可以延伸閱讀David Patterson 如何從 RISC 與 RISC-V 走向 TPU 與 AI 系統架構，比較資料布局、運算資源與系統取捨如何互相影響。

官方資料與延伸查證

• MIT News：Michael Stonebraker 研究回顧
• PostgreSQL 官方歷史
• MIT CSAIL：Data Civilizer