Also, it’s our team’s favorite engine to translate both foreign SQL and foreign applications for PostgreSQL! We believe in transitions, not migrations - a gradual shift from the old database engine to the new, specifically to reduce risk and optimize results. Using a project like this makes a huge difference in achieving both these goals.
It’s been a little bit since the latest major version was released, but we’re still excited about what’s new and wanted to share.
Version 5.0 (release notes) came out on November 25, 2025 and there’s already been a minor version released since then (5.1 release notes) on December 18, 2025. These editions of the project were the direct result of massive efforts from the IvorySQL team to provide a lot of quality feature improvements as well as implement PostgreSQL 18 compatibility.
IvorySQL 5 brought a lot of necessary changes with it, including:
In particular, we really enjoy a lot of the functionality upgrades.
For example, IvorySQL now has better NULL handling, where NULL is now treated like an empty string in compatible mode (matching Oracle behavior) to avoid bugs during migration. So, when you have situations such as SELECT CONCAT('a' || NULL), IvorySQL will now return 'a' instead of following PostgreSQL’s behavior of returning NULL.
One enhancement we really enjoy is that you can now nest functions and procedures. Functions are able to be embedded inside other functions (like Oracle packages, but simpler, using only private methods). This lets you organize complex logic in one place.
Along the same lines, support was also added for DO [ LANGUAGE lang_name ] code [USING IN | OUT | IN OUT, ...].
Currently, we’re ingesting applications that range from only a few packages, procedures, and functions (around 10-50 objects) to massive data loads that include around 50,000 objects (10,000+ procedures and hundreds of packages).
While there are still many features that will need to be added over time, it considerably reduces the effort taken to complete the transition from Oracle to PostgreSQL successfully.
If you’re thinking about testing it for yourself, there are a plethora of options to get started (including building it from source, using containers, etc.)… and even a WASM build! This in particular allows IvorySQL to be run directly in the browser without having to fully install it locally; it’s very convenient to look at syntax support and take the first step into the world of PostgreSQL.
You can deploy the IvorySQL-WASM project locally in just a few steps, following the blog post IvorySQL published on the subject.
Or, you can try out the hosted WASM on the IvorySQL website.
Hoping to learn more about how to use IvorySQL yourself? Keep an eye out for recorded webinars on their website (coming soon!), or check out recordings from the HOW2025 conference in Jinan, China in the meantime.
The next conference in Jinan is already scheduled, from April 26th to the 28th! (By the way, the Call for Proposals is open until February 27th, 2026.)
Our team is happy to employ contributors to the IvorySQL project. Some of our team members (Cédric Villemain, Yasir Hussain Shah) have been recognized in the release notes for 5.0 and 5.1 - and we have more additions planned. For the next release, we have planned some exciting developments, including:
ENABLE/DISABLE constraint syntaxUTL_FILE package additionCREATE TRIGGER body (without needing to create a function beforehand)(+)We’re looking forward to seeing the result of ongoing community work for the next release as well. Many great features are actively being added; for example, recently a new contributor to the project, Rophy Tsai, added the DBMS_OUTPUT and DBMS_UTILITY packages: something widely used across Oracle-based SQL codebases. It was recently merged to IvorySQL’s main branch, and will likely be included in the next minor or major release.
For those looking to transition to or explore PostgreSQL without extensive modifications to their existing database logic and applications, IvorySQL (specially v5.x) offers a practical solution. A direct migration to PostgreSQL could, in some cases, require significant changes to both database objects and application code. IvorySQL helps bridge this gap, allowing a smoother adoption of PostgreSQL with greater compatibility.
More and more companies are seeking to free themselves from the costs and constraints of Oracle by migrating to PostgreSQL. But how can this transition be achieved without spending months on it? Here is a proven, fast and secure method, based on feedback and open source tools.
Before migrating, it is essential to take stock of the situation: we start by listing Oracle objects through performing a complete extraction (including tables, views, sequences, procedures, functions, and packages).
It is also important to communicate regularly with the client to refine findings and validate directions, as well as to identify dependencies (applications connected with which technology, jobs, interfaces, etc.).
Finally, identify the client’s Oracle-specific features (specific functions such as ROWID, DUAL, DBMS_XXX, etc.) and any other keywords requiring special attention.
The success of a transition to PostgreSQL – because it is indeed a gradual transition and not a migration – depends as much on strategy as it does on tools.
It is not enough to simply copy objects: you need to understand the subtleties of the Oracle engine and intelligently transpose them into the PostgreSQL universe.
Among the essential tools, Ora2Pg plays a central role. Not only does it generate clear inventory reports, it also automates the conversion of schemas, data and PL/SQL code. It is a valuable accelerator for well-structured projects.
But in some contexts, the reality is more complex. Many customers accumulate significant technical debt, with thousands of lines of procedural code. Attempting to rewrite everything in PL/pgSQL in a short period of time would exhaust teams and compromise the migration itself. Maintaining two code bases— one in PL/SQL, the other in PL/pgSQL— during a complete transition phase is often organisationally untenable.
This is precisely where IvorySQL offers a powerful alternative. This fork of PostgreSQL, enhanced with Oracle compatibilities (PL/SQL, ROWID, DUAL, etc.), significantly reduces the need for immediate rewriting. By combining IvorySQL with targeted documentation and business validation scripts, the transition is easier, more reliable, and above all, more controlled.
Once in production, teams have the time they need to gradually rewrite their procedural and remaining application code in PL/pgSQL, without pressure or functional disruption.
One of the great advantages of IvorySQL is that it performs part of the integration upstream. Thanks to its native support for PL/SQL, Oracle objects and Oracle-compatible syntax, many elements migrated via Ora2Pg work immediately without any major adaptation.
Of course, this does not eliminate the need for testing. On the contrary, it is essential to validate business behaviour in an IvorySQL pre-production environment. Procedures, functions, packages, triggers, and views must be tested with real-world cases, comparing the results between Oracle and IvorySQL to ensure functional equivalence.
Comparison scripts can be used to verify query responses, transaction effects, or the behaviour of migrated functions. But in many cases, IvorySQL significantly reduces the need for patches or rewrites, speeding up production and securing the transition.
A successful transition is not limited to technical aspects; it also relies on clear documentation and appropriate support. It is essential to write comprehensive test specifications for each complex object and module (procedure, package, trigger, etc.) in order to keep track of technical choices, adaptations made, and points of attention.
Support for client teams is just as important. Targeted workshops are used to share best practices, explain the differences between Oracle and PostgreSQL, and facilitate the adoption of IvorySQL.
Finally, a successful transition to PostgreSQL also depends on support for technical and functional teams. Targeted training sessions enable developers, DBAs, and project managers to learn the specifics of IvorySQL, understand the differences with Oracle, and quickly develop their skills.
This system also relies on structured technical support, which helps resolve issues, secure implementation choices, and facilitate communication between project teams and migration experts.
During a recent assignment for a private sector company, we supported the transition from an Oracle database to IvorySQL in a challenging context: where there was significant technical debt, high volume, and tight deadlines.
Thanks to IvorySQL and our ability to automate this transition, it was completed quickly and almost all objects were integrated without rewriting.
The switch from IvorySQL to PostgreSQL can be carried out smoothly, as long as the application is fully functional and meets business expectations.
The teams were able to focus on business testing, while targeted training and technical support enabled rapid skill development.
It is essential to succeed in this type of project in order to build confidence and roll out this operation across your entire Oracle instance fleet!
Are you considering a transition from Oracle to PostgreSQL? Let’s talk about it.
Contact our team of experts at any time: contact@data-bene.io
On November 26, 2025 IvorySQL 5.0 was released - view the announcement here for more information about this open-source project.
]]>