IvorySQL 1.23 Review: Oracle Compatibility on a PostgreSQL Base

What IvorySQL Actually Solves

IvorySQL targets a specific pain: teams that want to leave Oracle but are trapped by PL/SQL code and Oracle-specific SQL. The README states it is an 'open-source Oracle-compatible PostgreSQL' and highlights PL/iSQL, a procedural language that supports Oracle's PL/SQL syntax and Oracle-style packages. That is the core value. It is not a translation layer or a middleware product. It is a fork of PostgreSQL, so you get a database that behaves like PostgreSQL but can switch into an Oracle compatibility mode. The intended user is a developer or DBA migrating an existing Oracle application, or a team standardizing on PostgreSQL but needing to run some legacy Oracle code. The project commits to remaining a drop-in replacement for the latest PostgreSQL, which is a bold promise given how fast PostgreSQL evolves.

The Compatibility Mode Mechanism

The central switch is a GUC parameter named `ivorysql.compatible_mode`. The README says it 'switches between Oracle and PostgreSQL compatibility modes.' That is the entire documented mechanism. You set it, and the database changes its behavior for certain syntax and functions. The documentation does not explain which features change under the hood, but the existence of a separate `oracle_regression.yml` workflow in CI suggests there is a dedicated test suite for Oracle mode. The PL/iSQL language is the other pillar. It supports Oracle's PL/SQL syntax and packages, which means you can create procedures, functions, and packages that look like Oracle code. How deep that support goes is not specified in the README. The regression tests are the only evidence of coverage, and they are not enumerated. That is a real gap. You cannot tell from the repository whether your specific Oracle package will run without modification.

Getting It Running: Docker and Source Builds

The README gives two concrete build paths. The quickest is Docker. You run `docker compose up -d`, then `docker compose exec dev bash` to enter the container. Inside, you configure with `./configure --prefix=/home/ivorysql/ivorysql --enable-debug --enable-cassert --with-uuid=e2fs --with-libxml`, then `make -j$(nproc)` and `make install`. Initialization is Oracle-mode specific: `/home/ivorysql/ivorysql/bin/initdb -D data_ora -m oracle`. That `-m oracle` flag is the key. It sets the default mode at cluster creation. You then start the server with `pg_ctl -D data_ora start`. To verify the Oracle compatibility features, you run `make oracle-check`. The alternative is a Meson build, which requires a clean source tree. If you have run `./configure` before, you must run `make distclean` first. Then `meson setup build -Dcassert=true -Dbuildtype=debug`, `ninja -C build`, and run `./build/src/backend/postgres --version`. Meson is marked as an alternative, so the primary path is still autoconf. That matters if you are used to modern PostgreSQL builds, which have moved to Meson upstream.

The Dual Release Line Is a Warning Sign

The repository shows two active release lines: IvorySQL_1.23 and IvorySQL_5.4. Both received updates in 2026, with 1.23 pushed on 2026-07-27 and 5.4 on 2026-06-17. That is unusual. A single project with two major versions implies divergent feature sets or support cycles. The README does not explain the difference between the 1.x and 5.x lines. The documentation links point to v5.4, which suggests 5.x is the current major version. But 1.23 is still getting releases, so it is not abandoned. For a user, this creates a decision: which line do you install? The README does not answer that. You would have to dig into the release notes or the docs. This ambiguity is a maintenance risk. If you pick 1.x and the project focuses on 5.x, you may miss security fixes. The dual line also complicates the 'drop-in replacement for the latest PostgreSQL' claim, because 'latest' cannot mean both lines.

Where It Is the Wrong Tool

IvorySQL is not a magic wand for Oracle migration. The README claims Oracle compatibility, but it does not claim full SQL coverage. If your application uses advanced Oracle features like flashback queries, materialized view logs, or Oracle-specific data types beyond what PL/iSQL covers, you will likely hit a wall. The documentation is not included in the repository, only linked, so you cannot audit the compatibility surface from the source alone. The regression tests are a start, but they are not a guarantee. Also, the project is a fork of PostgreSQL, which means it will lag behind upstream PostgreSQL releases. The README says it is based on PostgreSQL and commits to being a drop-in replacement, but forks always carry a delay. If you need the newest PostgreSQL features immediately, IvorySQL is the wrong choice. For a pure greenfield project with no Oracle baggage, plain PostgreSQL is simpler and has a larger ecosystem. IvorySQL only earns its complexity when you have existing Oracle code.

The Real Alternative: Ora2Pg and Plain PostgreSQL

The main alternative is not another Oracle-compatible database. It is a migration tool like Ora2Pg, which converts Oracle schema and PL/SQL to native PostgreSQL. That approach keeps you on vanilla PostgreSQL, which has a massive community, frequent releases, and no fork lag. The difference in approach is fundamental. IvorySQL tries to run Oracle code as-is, by changing the database's behavior. Ora2Pg changes the code to fit PostgreSQL. The trade-off is clear. With IvorySQL, you preserve your PL/SQL but inherit a smaller project. With Ora2Pg, you rewrite code but stay on the mainstream database. There is also the option of using PostgreSQL's built-in PL/pgSQL, which is similar to PL/SQL but not identical. If your Oracle code is simple, a manual rewrite to PL/pgSQL may be trivial. The README does not mention Ora2Pg, but that is the natural comparison. Your choice depends on how much code you have and how willing you are to modify it.

Licensing and Contribution Costs

IvorySQL is released under the Apache-2.0 license, which is permissive and allows commercial use, modification, and redistribution. That is a clear advantage over Oracle's proprietary license. However, the README notes that all contributors must sign a Contributor License Agreement (CLA) before submitting code. That is a governance cost. If you plan to contribute patches, you must sign the CLA. The README also has a specific section for AI coding assistants, requiring them to read `coding-assistants.md` before contributing. That is unusual and reflects a concern about AI-generated code quality. For maintenance, you need to track upstream PostgreSQL releases and merge them into the fork. The README does not document how often that happens. The CI workflows include `build.yml`, `contrib_regression.yml`, `meson_build.yml`, `pg_regression.yml`, and `oracle_regression.yml`, so there is some automated testing. But the dual release line means you may need to maintain compatibility with both. Upgrade cost is not documented, so you should plan for manual testing after each release.

Editorial conclusion

Adopt IvorySQL if you run PostgreSQL today and need a gradual path toward Oracle syntax, especially for PL/SQL packages, and if you can accept the risk of a smaller community than PostgreSQL itself. Do not adopt it if you require certified Oracle compatibility for a critical migration, because the documentation and regression tests do not prove full coverage. Before committing, verify that your specific PL/SQL features and Oracle built-in functions work under the oracle compatible_mode, run the oracle-check suite on your target version, and review the release notes for 1.23 and 5.4 to see what changed recently. The project's promise of staying 100% compatible with PostgreSQL is strong, but you must test that promise against your own workload.

Official sources

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