IvorySQL 1.23 实测评估：Oracle 兼容层的真实边界在哪里

它解决什么问题：Oracle 迁移的中间路线

Oracle 数据库的授权成本与锁定效应让不少团队考虑迁移，但直接换到原生 PostgreSQL 意味着重写 PL/SQL 存储过程、包、触发器。IvorySQL 的定位是给你一个 PostgreSQL 内核，同时保留 Oracle 的编程模型。它通过 `ivorysql.compatible_mode` 这个 GUC 参数在 Oracle 和 PostgreSQL 兼容模式之间切换，而不是像某些项目那样只做语法翻译。这意味着你可以在同一个实例里，用 Oracle 模式跑老代码，用 PostgreSQL 模式跑新应用。目标用户很明确：有 Oracle 存量资产、又不想彻底重写的开发团队，以及那些需要同时维护两套数据库逻辑的中间态组织。

PL/iSQL 与 Package：兼容层的核心机制

IvorySQL 的亮点是 PL/iSQL，一个支持 Oracle PL/SQL 语法和 Oracle 风格 Package 的过程语言。从 README 看，它不是简单的语法糖，而是作为 PostgreSQL 的一个过程语言扩展存在。Package 在 Oracle 里是组织存储过程、函数、变量和游标的容器，IvorySQL 实现了这种容器语义。你可以在 PL/iSQL 里写 `CREATE PACKAGE`，然后像在 Oracle 里一样调用包内的过程。这个机制与 PostgreSQL 原生的 PL/pgSQL 有本质区别：PL/pgSQL 没有包的概念，只有独立的函数。IvorySQL 相当于在 PostgreSQL 的 `CREATE FUNCTION` 之外，额外实现了一套包管理。但 README 没有说明包内状态（如包级变量）是会话级还是事务级，这会影响并发行为。如果包变量是会话级的，那在高并发下可能产生与 Oracle 不同的隔离表现。

安装与构建：Docker 是唯一被完整描述的路径

README 给出了四种安装方法：Yum、Docker、Rpm、源码。但只有 Docker 开发流程有完整命令。你可以用 `docker compose up -d` 启动开发容器，然后 `docker compose exec dev bash` 进入。配置命令是 `./configure --prefix=/home/ivorysql/ivorysql --enable-debug --enable-cassert --with-uuid=e2fs --with-libxml`，构建用 `make -j$(nproc) && make install`。初始化数据库时用 `initdb -D data_ora -m oracle` 指定 Oracle 模式，这比启动后再改 GUC 更干净。测试命令是 `make oracle-check`，说明有专门的 Oracle 兼容性回归测试套件。另外提供 Meson 构建作为替代，但要求干净源码树，如果之前跑过 `./configure`，必须 `make distclean`。对我来说，Docker 路径最省事，但生产部署大概率走 RPM 或源码，而文档链接没有展开具体步骤，这是评估时的一个盲点。

GUC 切换：一个参数，两种世界

`ivorysql.compatible_mode` 是理解 IvorySQL 的关键。它让你在 Oracle 和 PostgreSQL 模式之间切换，但 README 没有说明切换的粒度。是实例级还是数据库级？是会话级还是事务级？如果只能在 initdb 时指定（如 `-m oracle`），那切换成本很高。如果运行时可改，那可能影响正在执行的查询。另一个问题是，切换后哪些行为会变：是只影响 PL/SQL 语法解析，还是连数据类型、函数、操作符、系统视图都变？比如 Oracle 的 `VARCHAR2` 和 PostgreSQL 的 `VARCHAR` 在长度语义上不同，Oracle 的 `NVL` 与 PostgreSQL 的 `COALESCE` 在类型推断上有差异。README 只提到“兼容模式”，没有列出具体差异清单。这意味着你必须在测试环境里逐一验证，而不能依赖文档。

版本线分裂：1.23 与 5.4 并存意味着什么

最近的 release 显示两个版本线并行：1.22、1.23 和 5.4。1.x 系列看起来是稳定分支，5.x 可能是开发主线。这种双版本策略在开源数据库里常见，但对用户来说是个负担。你选 1.23 可能更稳定，但缺少新特性；选 5.4 可能更接近未来方向，但文档链接指向 v5.4，说明文档主力在 5.x。README 没有说明两个版本线的维护周期、安全更新策略、以及它们分别对应哪个 PostgreSQL 上游版本。PostgreSQL 每年一个大版本，IvorySQL 需要同步，但同步延迟是多少？如果 5.4 基于 PostgreSQL 16，那 1.23 可能基于 15 或更早。你在评估时，必须去 release notes 里确认版本对应关系，否则可能选了一个已经失去上游安全补丁的版本。

许可证与贡献门槛：Apache-2.0 但要求 CLA

IvorySQL 采用 Apache-2.0 许可证，这比 PostgreSQL 的 PostgreSQL License 更宽松，允许修改后闭源使用。但贡献代码前必须签署 Contributor License Agreement (CLA)，这在国内开源项目里常见，但会阻止一些匿名或临时贡献。README 还特别提到 AI 编码助手必须阅读 `coding-assistants.md`，说明项目对 AI 生成代码有额外要求。这本身不是坏事，但如果你打算用 Copilot 或 ChatGPT 辅助开发，需要先读那个文件。许可证方面，Apache-2.0 对商业使用友好，但要注意它不包含专利授权条款中的某些限制，具体法律问题得咨询律师。维护成本上，你实际上是在 fork PostgreSQL，所以必须跟踪上游安全公告，并及时合并。项目提供 CI 工作流（`build.yml`、`pg_regression.yml`、`oracle_regression.yml`），说明有自动化测试，但没看到覆盖率或发布频率数据。

替代方案：EDB 与纯 PostgreSQL 的取舍

IvorySQL 不是唯一做 Oracle 兼容的 PostgreSQL 分支。EDB Postgres Advanced Server 是商业产品，提供更成熟的 Oracle 兼容层，包括 `edb-compatible` 模式、`DBMS_*` 包、`REF CURSOR`、`%TYPE` 属性等，但需要付费订阅。IvorySQL 是开源的，但兼容范围可能更窄。另一个方向是使用原生 PostgreSQL 加 `orafce` 扩展，它提供 Oracle 风格的函数和操作符，但不支持 PL/SQL 包语法。如果你的应用只用了 `NVL`、`SYSDATE` 这类函数，`orafce` 就够了，不需要整个分支。IvorySQL 的优势在于它从内核层面支持 PL/SQL 包，这是 `orafce` 做不到的。但代价是你要维护一个独立分支，而 `orafce` 只是插件，升级 PostgreSQL 时风险更小。

真正的风险：文档空白与测试深度

README 反复强调“100% 兼容”和“drop-in replacement”，但这是营销语言，不能当技术承诺。文档链接指向 v5.4，但 1.23 是最近推送的，说明文档可能滞后于代码。`oracle_regression.yml` 工作流存在，说明有回归测试，但测试覆盖多少 Oracle 语法？`make oracle-check` 能跑，但测试套件是否包含 PL/SQL 包、异常处理、游标变量等高级特性？没有证据。另一个风险是，GUC 切换可能影响 PostgreSQL 自身的优化器行为。在 Oracle 模式下，`NULL` 排序、字符串连接、`GROUP BY` 语义可能与 PostgreSQL 默认不同，这会导致查询计划变化。你必须在真实数据量下做性能对比，而不是只跑功能测试。

编辑结论

IvorySQL 适合那些已经深度使用 PostgreSQL、但需要迁移部分 Oracle PL/SQL 存量代码的团队，尤其是能接受维护分支版本、愿意参与社区反馈的用户。不适合需要完整 Oracle 语义（如高级队列、RAC、精细权限模型）的生产系统，也不适合追求与上游 PostgreSQL 同步速度的团队。采用前先验证三件事：你的 PL/SQL 包是否依赖 Oracle 特有内置包（如 DBMS_SCHEDULER）、GUC 切换是否影响现有查询计划、以及社区对 1.23 与 5.4 两个版本线的维护策略。若你只是想要一个稳定的 Oracle 替代品，直接评估 EDB Postgres Advanced Server 或 YugabyteDB 的兼容层可能更省心。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes