很多國產(chǎn)數(shù)據(jù)庫都以 “兼容 Oracle” 作為賣點，說實話，老馮一直都對這件事不感冒。有時候我也會懷疑，PG 去兼容 Oracle 到底是不是一個偽需求—— 改改業(yè)務(wù)代碼能死嗎？但是最近我真的碰到了一個極端情況，讓我略微改了看法。

一個沒有源碼的 JAR 包

最近老馮接了個小活兒，挺有意思的。某 500 強車企，手里跑著一套 EDB —— 也就是 EnterpriseDB 出品的、帶 Oracle 兼容的 PostgreSQL。版本是 9.1。

9.1 是什么概念？2011 年 9 月發(fā)布的版本，到今天已經(jīng)整整 15 年 了。

這套系統(tǒng)跑在某個云平臺上（美國信創(chuàng)云），出過好幾次大故障（500 IOPS 的乞丐云盤跑 22TB 的生產(chǎn)數(shù)據(jù)庫）?？蛻艚K于忍不了了，找到我說：老馮，幫我們升一下級吧。升級本身不難，但從 9.1 到現(xiàn)在的 PG 18，中間差了十五個大版本，一年一個。這個跨度屬實有點大。

不過真正要命的不是版本跨度，而是他們的應(yīng)用 —— 沒有源碼了。

對，你沒聽錯。就是一個 JAR 包，代碼全寫死在里面了，改不了。更麻煩的是，這個 JAR 包里的 SQL 用了 EDB 提供的 Oracle 兼容語法，比如 SYSDATE。

不過有一點還是非常讓人震撼的：除了這一點不兼容（也是因為當年 Oracle 遷移 EDB PG 偷懶，留下了 Oracle 的尾巴）之外，其他的祖?zhèn)鳂I(yè)務(wù)代碼從 15 年前的老 PG 升級到最新的 PG 18，竟然沒有其他不兼容的地方。

為什么 SYSDATE 這么棘手？

SYSDATE 在 Oracle 里是一個內(nèi)置的關(guān)鍵字/變量，用來獲取當前時間戳，類似于 PostgreSQL 里的 current_timestamp。

你可能會想：這有什么難的？建個函數(shù)不就完了嗎？

CREATE FUNCTION sysdate() RETURNS timestamp(0) AS
$$SELECT clock_timestamp()::timestamp(0) $$ LANGUAGE SQL;

沒那么簡單。問題在于，應(yīng)用里寫的不是 sysdate() 這種函數(shù)調(diào)用語法，而是直接用 SYSDATE 這個光禿禿的標識符。在 PostgreSQL 的 Parser（解析器）看來，這個東西既不是函數(shù)調(diào)用，也不是已知的關(guān)鍵字。Parser 直接就不認識它，報語法錯誤。

而且，你無法通過寫擴展來解決這個問題。PostgreSQL 的可擴展性覆蓋了絕大多數(shù)場景 —— 你可以自定義類型、操作符、索引方法、存儲引擎、執(zhí)行邏輯、甚至外部數(shù)據(jù)源。但唯獨語法，是不允許通過擴展來定制的。 這是 PostgreSQL 可定制性上唯一的遺憾。

要讓 PostgreSQL 認識 SYSDATE 這個 token，你必須去改 Parser 的語法規(guī)則文件，也就是要動內(nèi)核源碼。

如果應(yīng)用有源碼，這事兒根本不叫事兒 —— 現(xiàn)在用 AI 做個全局替換，把 SYSDATE 改成 clock_timestamp()::timestamp(0)，分分鐘搞定。但源碼沒了，JAR 包寫死了，這條路堵死了。

你讓我怎么辦？去反編譯 JAR 包然后改 SQL 字符串字面值？這聽著就不太靠譜。所以你看，臟活累活最后全跑到數(shù)據(jù)庫這兒來了。

IvorySQL：開源的 Oracle 兼容內(nèi)核

雖然需求很扯淡，但既然是客戶的活兒，還是要想辦法。

我琢磨了一下，能在 PG 內(nèi)核層面提供 Oracle 語法兼容的，目前就那么幾家。做得最好的是 EDB，接著用 EDB 就沒這個問題。但 EDB 是商業(yè)產(chǎn)品，價格不菲，而且人家本來就準備換開源。

國內(nèi)號稱兼容 Oracle 的數(shù)據(jù)庫倒是一堆，但人家客戶不吃信創(chuàng)這一套。所以 PolarDB-O 也不可能（而且也跟 EDB PG Oracle 兼容有說不清道不明的微妙聯(lián)系，據(jù)說有些其他國產(chǎn)數(shù)據(jù)庫也是 EDB 貼牌）。

所以我想了一下，還真就只有 IvorySQL 能干這個事。IvorySQL 是瀚高做的一個開源項目，Apache 2.0 許可證，基于 PostgreSQL 內(nèi)核提供 Oracle 兼容性 —— 包括 PL/SQL、Oracle 語法、內(nèi)置函數(shù)、數(shù)據(jù)類型、系統(tǒng)視圖等等。最新的 IvorySQL 5.1 與 PostgreSQL 18.1 保持同步。

這里要說明一下，IvorySQL 的 Oracle 兼容是 SQL 語法層面 的兼容，不是線纜協(xié)議兼容。也就是說，客戶端還是用 PostgreSQL 的驅(qū)動來連接，但連上之后可以跑 Oracle 風格的 SQL。能理解這里的考慮 —— Oracle 的法務(wù)在業(yè)界可是臭名昭著的，搞客戶端協(xié)議兼容怕是要被告。

而且關(guān)鍵的是：IvorySQL 只是一個內(nèi)核，Pigsty 能把它變成一個完整的 RDS。

高可用、備份恢復(fù)、監(jiān)控、IaC —— 全都和 Pigsty 原生整合。拉起一套這樣生產(chǎn)級的 RDS 服務(wù)，使用 IvorySQL 這個 Oracle 兼容的內(nèi)核，聽起來很復(fù)雜，但實際上簡單到令人發(fā)指，找臺 Linux 服務(wù)器執(zhí)行：

curl -fsSL https://repo.pigsty.cc/get | bash; cd ~/pigsty
./configure -c ivory # 使用 IvorySQL 配置模板
./deploy.yml

三條命令，一個 Oracle 兼容的 PG RDS 就拉起來了。你要想加從庫，也是一行命令的事情。備份，恢復(fù)，高可用， 監(jiān)控系統(tǒng)，全都預(yù)先弄好了！

讓我們來看看，連接 5432 PG 默認端口，使用 Oracle 的 SYSDATE 查詢就報錯了，切換到 1521 Oracle 兼容端口，it works！

總的來說，這套方案相當完美地解決了歷史遺留的 Oracle 兼容應(yīng)用的問題。這也讓我發(fā)現(xiàn)，雖然是一個很冷門的生態(tài)位，但確實有用戶有這個需求。反正對老馮來說，這就是很簡單的事情，順手做了也就做了。

這活兒老馮收了 5 萬塊一年。相比 EnterpriseDB 的訂閱費，那簡直不知道要便宜到哪里去了。光買云服務(wù)跑這玩意的資源一年都要花幾十萬。當然話又說回來了，老馮也不提供 IvorySQL 的質(zhì)保。如果 IvorySQL 炸了，你找瀚高去。我只管 Pigsty RDS 不出問題，不過老馮自己覺得呢，IvorySQL 沒有魔改太多，而是做的增量特性，這個還是相對可控的。我在實際安裝使用測試的時候，也還沒遇到過 crash 或者 dump 的情況。而且這年頭，內(nèi)核爆炸的情況確實已經(jīng)很罕見了。

Pigsty：一個"元發(fā)行版"

說完 IvorySQL 這個案例，順便聊聊 Pigsty 最近在內(nèi)核這塊干的幾件事。

Babelfish 內(nèi)核重建。 這是 AWS 出品的 SQL Server 兼容內(nèi)核。之前老粉為了偷懶，用的是 WiltonDB 打包的版本，但那個包比較老，還停留在 PG15，而且只支持 EL8/EL9 和 Ubuntu 22.04/24.04，缺 Debian 和 EL10 的支持，用起來還要用它的專有倉庫，總感覺差點意思。

所以這次我一不做二不休，讓 Codex 幫我把 Babelfish 的打包流程按 Pigsty 的標準重建了一遍。現(xiàn)在 Babelfish 不再依賴 WiltonDB 的倉庫，直接從 Pigsty 自己的倉庫安裝，全平臺通吃了，版本也升級到 PG 17，使用體驗也更好了。

Cloudberry 數(shù)倉內(nèi)核。 既然做了 Babelfish，我也順手把 Apache Cloudberry（基于 Greenplum 7 的開源數(shù)倉）也打包了。之前 1.6 版本的時候起碼還提供 EL8/EL9 的 RPM 包，結(jié)果 2.0 到現(xiàn)在等了好幾個月，都沒有二進制產(chǎn)物，問了也是說暫時沒這個計劃。

所以我也干脆自己上了，Codex 一把梭，把 EL 8-10，Debian 12/13 ，Ubuntu 22/24 x86_64/ARM64 總共 14 個 Linux 平臺上的 RPM/DEB 包都打好了。這其實是個挺復(fù)雜的大活兒，但 Codex 在那兒"糊"了半天，跑了各種集成測試和單元測試，還弄了幾個 Patch 才在 EL10/Debian13 上跑通，最后總算搞定了。

除此之外，OrioleDB 更新到 Beta 14。Percona PGTDE 更新到 18.1。

所以你看，這就是 Pigsty 好玩的地方 —— 它不僅僅是一個 PostgreSQL 發(fā)行版，它是一個 元發(fā)行版。你不僅可以在原生的 PG 上使用 450 多個擴展插件，而且就連 PG 這個內(nèi)核本身都是可以替換的。

你可以根據(jù)需求，愛用什么內(nèi)核就用什么內(nèi)核：

?想要 Oracle 兼容 → IvorySQL 內(nèi)核，還有 Polar-O 內(nèi)核?想要 SQL Server 兼容 → Babelfish 內(nèi)核?想要 MongoDB 兼容 → DocumentDB 擴展 + FerretDB?想要 極致 OLTP 性能 → OrioleDB 內(nèi)核?想要 透明數(shù)據(jù)加密 → PGTDE 內(nèi)核?想要 分布式水平擴展 → Citus 內(nèi)核?想要 數(shù)據(jù)倉庫 → Cloudberry 內(nèi)核

而無論你選哪個內(nèi)核，Pigsty 提供的監(jiān)控、高可用、備份恢復(fù)、IaC 能力都是一樣的。內(nèi)核可以換，平臺的能力不變。 這才是發(fā)行版該干的事。