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

一個沒有源碼的 JAR 包

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

9.1 是什么概念？2011 年 9 月發布的版本，到今天已經整整 15 年 了。

這套系統跑在某個云平臺上（美國信創云），出過好幾次大故障（500 IOPS 的乞丐云盤跑 22TB 的生產數據庫）。客戶終于忍不了了，找到我說：老馮，幫我們升一下級吧。升級本身不難，但從 9.1 到現在的 PG 18，中間差了十五個大版本，一年一個。這個跨度屬實有點大。

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

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

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

為什么 SYSDATE 這么棘手？

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

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

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

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

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

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

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

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

IvorySQL：開源的 Oracle 兼容內核

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

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

國內號稱兼容 Oracle 的數據庫倒是一堆，但人家客戶不吃信創這一套。所以 PolarDB-O 也不可能（而且也跟 EDB PG Oracle 兼容有說不清道不明的微妙聯系，據說有些其他國產數據庫也是 EDB 貼牌）。

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

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

而且關鍵的是：IvorySQL 只是一個內核，Pigsty 能把它變成一個完整的 RDS。

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

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

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

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

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

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

Pigsty：一個"元發行版"

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

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

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

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

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

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

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

你可以根據需求，愛用什么內核就用什么內核：

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

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