資料庫即架構

資料庫是業務架構的核心，是不言自明的共識。但如果我們更進一步，將資料庫作為業務架構本身，將業務邏輯甚至 HTTP Server 都放入資料庫中，又會有怎麼樣的火花？

在1月4日舉辦的第七屆PG生態大會上，我邀請尤里來中國，進行了題為《資料庫驅動未來》的主題分享。他丟擲了這個觀點 —— 資料庫就是業務架構。簡單說，他的開源 PostgreSQL 專案 —— Omnigres ，嘗試把所有應用的業務邏輯，甚至是 HTTP 伺服器都放入 PostgreSQL 資料庫中。

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

資料庫是架構的核心

“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.”。

資料庫祖師爺邁克·石破天（Michael Stonebraker）有句名言：“如果你給我看軟體架構，我對你的業務一無所知；但如果你給我看資料模型，我就能精準知道你的業務是幹嘛的”

無獨有偶，微軟的 CEO 納德拉也公開表示：我們今天所稱的軟體，其實只是資料庫上的一個華麗介面。他將其簡化為一個叫“CRUD”的概念：建立（Create）、讀取（Read）、更新（Update）和刪除（Destroy）。

也就是說，你喜歡的那些應用程式，不過是包裝精美的資料庫操作介面而已。BTW， Nadella 還提出 SaaS is Dead：因為以後 Agent 可以直接繞過中間商，代替前後端去讀寫資料庫了。

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

資料庫是業務架構的核心，是不言自明的共識。但如果我們更進一步，將資料庫作為業務架構本身，又會如何？

什麼，還能這麼玩

在 PG 生態大會上，尤里展示了一個思路：把所有業務邏輯，甚至是Web伺服器都塞進 PostgreSQL 裡。比如可以透過寫儲存過程，把原本後端的一部分功能直接放到資料庫裡執行。為此，他還基於 PG 擴充套件做了很多“標準庫”，從 HTTP、vfs、os 到 Python 模組，都可以內嵌在 PostgreSQL 中。

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

是的，夭壽啊，PostgreSQL 資料庫竟然拉起來了一個 HTTP 伺服器，預設跑在 8080 埠！你可以把它當成 Nginx 用！

但更重要的是，你還可以將任意的 PostgreSQL 函式（支援 20 多種儲存過程語言）掛載到 HTTP 端點上，實現你想要的任何東西。像這樣的 Omni 擴充套件總共有 33 款，當然也不要忘了 PG 生態裡還有接近 400 個開箱即用的擴充套件外掛可以提供各種功能

這一套擴充套件全家桶，提供了在 PostgreSQL 中進行 Web 開發的能力！

在資料庫中跑Web伺服器是餿主意嗎？

PostgREST 和 Postgraphile 這樣的工具，可以將設計良好的 PostgreSQL Schema 直接轉化為開箱即用的 RestAPI，而類似 Omnigres 這樣的工具乾脆百尺竿頭更進一步，直接讓 HTTP 伺服器執行在了 PG 資料庫內部！

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

早先在探探在使用 PostgreSQL 時，幾乎所有的業務邏輯（甚至推薦演算法）都在 PostgreSQL 裡實現，後端只負責很輕的一層封裝只不過，這種做法對開發者、DBA 的綜合技能要求較高，畢竟寫儲存過程、維護複雜的資料庫邏輯不是一件輕鬆活兒。而且那個時候，資料庫通常也是整個架構中的效能瓶頸，哪有餘量給這些花活。

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

資料庫中跑Web伺服器的利弊

在資料庫中跑Web Server這種模式有一些好處：

•你的業務邏輯，業務模型，業務資料放在一個地方，用統一的方式來管理。•你的業務程式碼就是一個放著 Python / JS / Java 等儲存過程的目錄，更新發布，CI/CD 都非常簡單。如果負載高要降級，把非關鍵的儲存過程重新整理或在資料庫裡設定標記就實現了。•儲存過程避免了應用後端與資料庫的多次網路RT，通常有更好的延遲表現（總吞吐量會下降，但以當下的硬體水平與效能餘量，Who cares！）•你所需要的只有一個 PostgreSQL 資料庫，後端融入到資料庫裡，運維管理極為便利，方便進行單元化部署與敏捷交付。

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

1.網際網路時代，資料庫是瓶頸，難以伸縮，大家希望透過讓應用承擔更多，資料庫退後的方式解決 scale 的問題。2.對開發者水平的要求太高了，用好資料庫對開發者本身已經是一件很有挑戰的事情，而寫儲存過程的技能在年輕一代開發者中幾乎已經失傳了，維護管理更是對 DBA 提出了極高的要求。

但隨著時代發展，這兩個主要問題得到了解決：硬體的發展讓資料庫的效能重新出現巨大的富餘。AI 的出現讓開發者的水平（AI加持下）得到了突飛猛進的發展。

前者讓資料庫效能餘量重新回到了一個可以在大多數場景下容納業務邏輯的地步，後者解決了開發者不會寫儲存過程的問題。因此在當下，資料庫即架構（DBaaA）成為了一種非常值得探索的實踐。

資料庫即架構理念有一個非常成功的案例 —— Supabase —— 可能有 80% YC 創業公司都在使用它。Supabase 號稱自己是一個 Backend as a Service，將 PostgreSQL，物件儲存，以及 EdgeFunction 封裝成為一整個執行時，然後將後端與傳統意義上的資料庫整體打包成為一個 “新的資料庫”。