AI時代的數據庫與DBA將何去何從

前天在 HOW 2025 大會的圓桌上，蕭主席問了一些關于 AI，數據庫 DBA 有趣的問題，以下是老馮的觀點，整理發出。

OLTP / OLAP ，誰先被革命？

問題：OLTP / OLAP 領域，AI 在哪個領域更有可能先帶來 “革命性” 的變化，DBA， 數據分析師，架構師又該如何應對這些變化。

老馮：“革命性”的意思說白了就是直接把工作崗位干沒了。對于 OLTP 領域，這意味著 AI 干掉 DBA ，對于 OLAP 領域，這意味著干掉數據分析師，數據研發的工作。目前的趨勢很顯然，OLAP 領域的工作崗位正在被替代中，大量 NL2SQL 的方案正在涌現。

與此同時，Claude Code 正在以驚人的水平替代著中低級程序員，寫 SQL 的數據分析師與數據研發作為一種 Coding 工種，也落在替代光譜中。我們可以看到各種各樣的 “智能分析” / 表格，數據庫 MCP，Text2SQL / NL 2SQL 的方案到處冒泡。

然而不同于 Github 上到處都是語料的編程數據樣本，運維/數據庫管理經驗的公開數據積累是非常少的。SRE，DBA 則因為語料數據缺乏，加上反饋驗證回路過長，在短期內還難以被直接替代。因此毫無疑問 AI 帶來的 “革命性” 變化會首先發生在 OLAP 領域。

一個鮮活的例子是，OpenAI 創始成員（），Vibe Coding 之父安德烈·卡帕西（Andrej Karpathy）在 YC AI創業學院發表了主題演講就提到過，他花了一天時間就糊出來一個菜單配圖的應用，但是花了整整一周時間才把這個應用給部署上線 —— OPS 部份成了 Vibe Coding 的瓶頸。

盡管如此，Agent 替代 DBA 也只是一個時間早晚的問題。也許三年，也許五年，最終 OLTP 領域的 DBA 工作也會在幾年內被 AI 攻克。云計算和本地管控軟件會自動化掉 70% - 90% 的工作，而 AI Agent 會處理剩下 9% 的工作，可能留下不到 1% 甚至 千分之一的疑難雜癥給頂級 DBA 處理。

一體化還是專業化，如何選型？

問題：數據庫領域會走向 ”一體化“ 還是 ”專業化“，企業如何針對自己的需求進行合理選擇？

老馮：許多領域都存在一個 “鐘擺”，根據力量強弱對比來回擺動。在當下，硬件性能突飛猛進，數據庫（PostgreSQL）擴展越來越豐富。現在數據庫領域的鐘擺顯然在向 “一體化” 擺動的，而留給專業化組件的生態位越來越小了。

前些日子，有個朋友問我一個向量 RAG 場景，應該用 PostgreSQL + pgvector 還是 Milvus，我問你有多少數據量 —— 兩千萬條。我回復說這個數量級您就別折騰了，一百多GB的數據放 PG 灑灑水，十幾TB 的PG向量表我都見過照樣跑的好好的。你要是數據量再翻個幾百倍，，而你現在已經用著PG，這么點規模就開始折騰，那不是給自己找事嗎？

同理，我也見過好幾次有業務號稱自己有超高增長，一上來就要申請一套水平分片庫，最后只有 幾十GB數據的滑稽故事。如果你的數據連幾十TB都沒有，那根本用不上什么分布式 NewSQL 數據庫 ——，那 99.99% 的業務也可以靠一個 PostgreSQL 解決所有問題。，。

我們可以把 PostgreSQL 這樣的數據庫比做智能手機，它可以打電話，GPS 導航，照相，干各種各樣的事情。確實存在專業的場景 —— 比如航海需要衛星電話，商業攝影可能需要專業單反相機，但這些小眾領域相比智能手機的市場規模差了好幾個數量級，而絕大多數用戶都只需要一款手機就足夠解決他們的問題了。

我認為在當下，對象存儲還值得有專用數據庫產品。其他的數據庫細分領域生態位基本已經收斂到上面的狀態。而且使用專用組件的門檻也越來越高，越來越遠離大部份應用的規模。我們可以期待再將來的某個時間點，（ / Timescale / Promescale ）。

過早優化是萬惡之源 —— 為了自己不需要的屬性付出復雜度，成本，人力，一致性維護上的代價沒有意義。企業在數據庫選型的時候一定要擦亮眼睛，不要為了自己并不需要的東西而瞎忙活 —— 而 PostgreSQL 毫無疑問就是數據庫領域的默認安全牌。

AI 時代的 DBA，何去何從？

問題：從 DBA 到 DBAA，DBA 如何適應 AI 時代的變化與沖擊

，效果非常不錯。你可以把 Claude Code 當成一個月薪一百美元的高級工程師（實際上你可以用 20刀套餐，買好幾個！），勤勤懇懇的二十四小時給你干活。這意味著什么？這意味一個光桿架構師現在有了一整個待命的高級程序員團隊。

AI 是極度利好專家的，在專家手中的 AI 能發揮出普通工程師 10x 的表現 —— 這背后的邏輯是專家能一步到位提出正確的問題，精準的上下文，以及直覺判斷，并且有能力對 Code Agent 的方案進行 Verfiy。而普通開發者則往往缺乏答案驗證能力與問出正確問題的健全直覺。而架構師可以指揮一堆 Code Agent 替代初級工程師去出活。

這也意味著，IT 領域將很有可能出現階層固化與分裂 —— 初級工程師的上升路徑被 Code Agent 鎖死了，被固化為 Code Agent 的傳聲筒與人肉膠水。而且因為沒有那么多場景和故障再給新人打磨練手成長，以后高級的DBA 和架構師可能也就是那么多。

對于金字塔尖的專家來說，這是一個重大利好，這意味著專家的能力可以通過以下兩種方式實現高速復制：通過 Coding Agent，；然后在前面的基礎上，再通過 DBA Agent，將專家的經驗沉淀為 Prompt / 知識庫，解決 9% 的常規問題，剩下的 1% （也許是 0.1% ）的活，再由專家人工解決。

這意味著一個 DBA 數據庫專家可以通過管控與Agent 實現幾百倍到上千倍的杠桿。例如，許多客戶咨詢我的問題，我是丟給 GPT o3-pro 解決的，我只需要問出正確的問題并驗證回答有效性，就可以完成原本需要十幾倍時間的工作。而這就是超級個體與一人公司的運作方式，讓我在一個人服務十幾個客戶的情況下依然可以時間自由。我將這種新的模式稱為 Service as Software （SaaS）。

實際上這也是云廠商云數據庫 RDS 團隊的工作模式，像德哥這樣的頂級 PG DBA 專家可以通過云管控軟件，一二三四線客服與 Agent 服務成千上萬的客戶。當然，他以前可能要依賴云平臺的能力，但現在有了開源的 PG 管控平臺 Pigsty，他完全可以出來當一個 PG 顧問，用 Pigsty 交付，用 Agent 輔助，自己負責問問題與兜底，同樣成為一個數據庫超級個體。

對于普通的 DBA 來說，我認為這里也有很多機會。一個顯著的趨勢是，數據庫的專業知識成為了 Vibe Coding 中不可替代性最強的部份。為什么這么說，讓我們看看現在的 AI / SaaS 創業者都是怎么交付，怎么出活兒的。

最佳實踐通常是用 Next.js 糊個前端托管到 Vercel 或者 Cloudflare 上，后面對接一個 Supabase 這樣的 “BaaS” 數據庫 —— 后端被完全省略掉了，而前端用 Vibe Coding 去糊相對容易，唯獨對 Supabase 底下的 Postgres 的掌握與理解，是相對稀缺的技能。而自建維護生產級 PostgreSQL / Supabase 集群，則基本上成為了整套 Stack 中的瓶頸卡點。

這對 DBA 是一個非常大的利好 —— 因為 Claude Code 把大家的編程能力拉到了同一個水準，那么比拼的就是通用的整合能力，以及稀缺的數據庫 / DBA經驗。而 PG DBA 群體恰好已經擁有了后者，那么相對于其他同級別工程師來說就占據了一個先天的優勢。

而 PG DBA 應該充分利用好當下這個優勢，使用 Code Agent （以及 開源 PostgreSQL 數據庫管控 Pigsty）武裝自己，把自己改造成新一代的全能架構師 + 管理者，在別人還在吭哧吭哧啃數據庫硬骨頭的時候搶先出擊，占領生態位高地。

老規矩，不打廣告，寫啥文章？

開源免費企業級 PostgreSQL 發行版：認準 Pigsty

https://pgsty.com ，這是市面上唯二兩個可以的開源 PostgreSQL 方案。 讓你在虛擬機/物理機/云服務器上一鍵安裝好帶有高可用， 備份恢復，監控系統，IaC，連接池，訪問控制的企業級 PostgreSQL / Supabase / MinIO / Redis / ... 數據庫服務，并一條龍解決好 Nginx，域名，HTTPS，Docker，鏡像，軟件源翻墻等問題 ……

數據庫老司機專欄