&

數(shù)據(jù)庫即架構：將數(shù)據(jù)庫作為業(yè)務架構本身，將業(yè)務邏輯甚至 HTTP Server 都放入數(shù)據(jù)庫中

admin

2025年1月26日 9:0 本文熱度 1901

數(shù)據(jù)庫是業(yè)務架構的核心，是不言自明的共識。但如果我們更進一步，將數(shù)據(jù)庫作為業(yè)務架構本身，將業(yè)務邏輯甚至 HTTP Server 都放入數(shù)據(jù)庫中，又會有怎么樣的火花？

在1月4日舉辦的第七屆PG生態(tài)大會上，我邀請尤里來中國，進行了題為《數(shù)據(jù)庫驅動未來》的主題分享。他拋出了這個觀點 —— 數(shù)據(jù)庫就是業(yè)務架構。簡單說，他的開源 PostgreSQL 項目 —— Omnigres ，嘗試把所有應用的業(yè)務邏輯，甚至是 HTTP 服務器都放入 PostgreSQL 數(shù)據(jù)庫中。

如果你覺得這聽上去有點不靠譜，先別急著下結論 —— 我也曾親眼目睹過這樣的成功實踐，所以今天就來和大家探討下這個有趣的話題。

數(shù)據(jù)庫是架構的核心

“If you show me your software architecture, I learn nothing about your business. But if you show me your data model, I can guess exactly what your business is.”。

數(shù)據(jù)庫祖師爺邁克·石破天（Michael Stonebraker）有句名言：“如果你給我看軟件架構，我對你的業(yè)務一無所知；但如果你給我看數(shù)據(jù)模型，我就能精準知道你的業(yè)務是干嘛的”

無獨有偶，微軟的 CEO 納德拉也公開表示：我們今天所稱的軟件，其實只是數(shù)據(jù)庫上的一個華麗界面。他將其簡化為一個叫“CRUD”的概念：創(chuàng)建（Create）、讀取（Read）、更新（Update）和刪除（Destroy）。

也就是說，你喜歡的那些應用程序，不過是包裝精美的數(shù)據(jù)庫操作界面而已。BTW， Nadella 還提出 SaaS is Dead：因為以后 Agent 可以直接繞過中間商，代替前后端去讀寫數(shù)據(jù)庫了。

即使在 GenAI 爆火的當下，絕大多數(shù)信息系統(tǒng)的整個 IT 技術棧依然是以數(shù)據(jù)庫為核心設計的。無論業(yè)務架構怎么折騰，底層的東西永遠是萬變不離其宗。所謂的分庫分表，幾地幾中心，異地多活這些架構花活，說到底也就是數(shù)據(jù)庫的不同使用方式罷了。

數(shù)據(jù)庫是業(yè)務架構的核心，是不言自明的共識。但如果我們更進一步，將數(shù)據(jù)庫作為業(yè)務架構本身，又會如何？

什么，還能這么玩

在 PG 生態(tài)大會上，尤里展示了一個思路：把所有業(yè)務邏輯，甚至是Web服務器都塞進 PostgreSQL 里。比如可以通過寫存儲過程，把原本后端的一部分功能直接放到數(shù)據(jù)庫里執(zhí)行。為此，他還基于 PG 擴展做了很多“標準庫”，從 HTTP、vfs、os 到 Python 模塊，都可以內(nèi)嵌在 PostgreSQL 中。

讓我們來看一個有趣的例子，在 PostgreSQL 中執(zhí)行以下 SQL，將會啟動一個 Web 服務器，將 /pg/bin/ （或者其他任何目錄）作為一個 Web 服務器的根目錄對外提供服務。

是的，夭壽啊，PostgreSQL 數(shù)據(jù)庫竟然拉起來了一個 HTTP 服務器，默認跑在 8080 端口！你可以把它當成 Nginx 用！

但更重要的是，你還可以將任意的 PostgreSQL 函數(shù)（支持 20 多種存儲過程語言）掛載到 HTTP 端點上，實現(xiàn)你想要的任何東西。像這樣的 Omni 擴展總共有 33 款，當然也不要忘了 PG 生態(tài)里還有接近 400 個開箱即用的擴展插件可以提供各種功能

這一套擴展全家桶，提供了在 PostgreSQL 中進行 Web 開發(fā)的能力！

在數(shù)據(jù)庫中跑Web服務器是餿主意嗎？

PostgREST 和 Postgraphile 這樣的工具，可以將設計良好的 PostgreSQL Schema 直接轉化為開箱即用的 RestAPI，而類似 Omnigres 這樣的工具干脆百尺竿頭更進一步，直接讓 HTTP 服務器運行在了 PG 數(shù)據(jù)庫內(nèi)部！

目前來說，這種實踐絕對算不上主流。站在一個 DBA 的角度來講，我肯定認為這是一個給 DBA 找麻煩的餿主意。但站在一個開發(fā)者，特別是前端開發(fā)者的角度來說，我認為這個主意還是很有意思，值得探索的！因為確實很省事 —— 前端一套 Next.js 一把梭，后端一個數(shù)據(jù)庫全部搞定了，架構簡單無比。

早先在探探在使用 PostgreSQL 時，幾乎所有的業(yè)務邏輯（甚至推薦算法）都在 PostgreSQL 里實現(xiàn)，后端只負責很輕的一層封裝只不過，這種做法對開發(fā)者、DBA 的綜合技能要求較高，畢竟寫存儲過程、維護復雜的數(shù)據(jù)庫邏輯不是一件輕松活兒。而且那個時候，數(shù)據(jù)庫通常也是整個架構中的性能瓶頸，哪有余量給這些花活。

但現(xiàn)在隨著兩個關鍵要素的變化（AI 的出現(xiàn)與硬件性能的嚴重過剩），利弊權衡發(fā)生了改變。GPT 顯然已經(jīng)達到了能夠熟練編寫存儲過程的中高級開發(fā)者的水準，而遵循摩爾定律發(fā)展的硬件直接把單機性能推到了一個匪夷所思的地步。

數(shù)據(jù)庫中跑Web服務器的利弊

在數(shù)據(jù)庫中跑Web Server這種模式有一些好處：

?你的業(yè)務邏輯，業(yè)務模型，業(yè)務數(shù)據(jù)放在一個地方，用統(tǒng)一的方式來管理。?你的業(yè)務代碼就是一個放著 Python / JS / Java 等存儲過程的目錄，更新發(fā)布，CI/CD 都非常簡單。如果負載高要降級，把非關鍵的存儲過程刷新或在數(shù)據(jù)庫里設置標記就實現(xiàn)了。?存儲過程避免了應用后端與數(shù)據(jù)庫的多次網(wǎng)絡RT，通常有更好的延遲表現(xiàn)（總吞吐量會下降，但以當下的硬件水平與性能余量，Who cares?。?/span>?你所需要的只有一個 PostgreSQL 數(shù)據(jù)庫，后端融入到數(shù)據(jù)庫里，運維管理極為便利，方便進行單元化部署與敏捷交付。

這種模式的主要弊病有兩個：

1.互聯(lián)網(wǎng)時代，數(shù)據(jù)庫是瓶頸，難以伸縮，大家希望通過讓應用承擔更多，數(shù)據(jù)庫退后的方式解決 scale 的問題。2.對開發(fā)者水平的要求太高了，用好數(shù)據(jù)庫對開發(fā)者本身已經(jīng)是一件很有挑戰(zhàn)的事情，而寫存儲過程的技能在年輕一代開發(fā)者中幾乎已經(jīng)失傳了，維護管理更是對 DBA 提出了極高的要求。

但隨著時代發(fā)展，這兩個主要問題得到了解決：硬件的發(fā)展讓數(shù)據(jù)庫的性能重新出現(xiàn) 巨大的富余。AI 的出現(xiàn)讓開發(fā)者的水平（AI加持下）得到了突飛猛進的發(fā)展。

前者讓數(shù)據(jù)庫性能余量重新回到了一個可以在大多數(shù)場景下容納業(yè)務邏輯的地步，后者解決了開發(fā)者不會寫存儲過程的問題。因此在當下，數(shù)據(jù)庫即架構（DBaaA）成為了一種非常值得探索的實踐。

數(shù)據(jù)庫即架構理念有一個非常成功的案例 —— Supabase —— 可能有 80% YC 創(chuàng)業(yè)公司都在使用它。Supabase 號稱自己是一個 Backend as a Service，將 PostgreSQL，對象存儲，以及 EdgeFunction 封裝成為一整個運行時，然后將后端與傳統(tǒng)意義上的數(shù)據(jù)庫整體打包成為一個 “新的數(shù)據(jù)庫”。

但 Supabase 本身仍然是一系列容器組件縫合拼接起來的，如果這種架構走到極致，大概會變成 Omnigres 的樣子 —— 一個運行著 HTTP 服務器的 PostgreSQL，Nothing Else。

這也許意味著軟件架構的鐘擺重新回歸簡單 —— 繞開花里胡哨的中間件，前端直接訪問數(shù)據(jù)庫，甚至連傳統(tǒng)移動/Web前端也許最終也會被 LLM Agent 與其他 Interface 替代。最后直接由 Agent 代理訪問數(shù)據(jù)庫。

那么要不要試試呢？

順便一提，我們已經(jīng)與 Omnigres 達成了合作。昨天在 Omnigres 創(chuàng)始人 Yurii 的幫助下，我為 Omnigres 構建了主流 Linux 上的 RPM/DEB 包，包含了了以下 33 個擴展插件，開箱即用。（https://ext.pigsty.io/#/omni）