C’est aussi le moteur préféré de notre équipe pour traduire à la fois le SQL étranger et les applications étrangères pour PostgreSQL ! Nous croyons en les transitions, pas les migrations — un déplacement progressif de l’ancien moteur de base de données vers le nouveau, spécifiquement pour réduire les risques et optimiser les résultats. Utiliser un projet comme celui-ci fait toute la différence pour atteindre ces deux objectifs.
La dernière version majeure est sortie il y a un peu de temps, mais nous sommes toujours enthousiastes quant à ce qui est nouveau et nous avons tenu à le partager.
La version 5.0 (notes de version) est sortie le 25 novembre 2025 et une version mineure a déjà été publiée depuis (notes de version 5.1) le 18 décembre 2025. Ces éditions du projet sont le résultat direct des efforts massifs de l’équipe IvorySQL pour fournir de nombreuses améliorations de qualité ainsi que pour implémenter la compatibilité avec PostgreSQL 18.
IvorySQL 5 a apporté de nombreux changements nécessaires, notamment :
En particulier, nous apprécions beaucoup les améliorations fonctionnelles.
Par exemple, IvorySQL dispose désormais d’un meilleur traitement des valeurs NULL, où NULL est désormais traité comme une chaîne vide en mode compatible (correspondant au comportement Oracle) pour éviter des bugs lors de la migration. Ainsi, dans des situations telles que SELECT CONCAT('a' || NULL), IvorySQL retournera désormais 'a' au lieu de suivre le comportement de PostgreSQL qui retournerait NULL.
Une amélioration que nous apprécions particulièrement est qu’il est désormais possible d’imbriquer des fonctions et des procédures. Les fonctions peuvent être intégrées dans d’autres fonctions (à la manière des paquets Oracle, mais plus simplement, en utilisant uniquement des méthodes privées). Cela permet d’organiser une logique complexe en un seul endroit.
Dans le même ordre d’idées, le support a également été ajouté pour DO [ LANGUAGE lang_name ] code [USING IN | OUT | IN OUT, ...].
Actuellement, nous intégrons des applications allant de quelques paquets, procédures et fonctions (environ 10 à 50 objets) à des chargements de données massifs incluant environ 50 000 objets (plus de 10 000 procédures et des centaines de paquets).
Bien que de nombreuses fonctionnalités devront encore être ajoutées avec le temps, cela réduit considérablement l’effort nécessaire pour achever avec succès la transition d’Oracle vers PostgreSQL.
Si vous envisagez de le tester vous-même, il existe une pléthore d’options pour commencer (y compris la compilation depuis la source, l’utilisation de conteneurs, etc.)… et même une compilation WASM ! En particulier, cela permet d’exécuter IvorySQL directement dans le navigateur sans avoir à l’installer localement ; c’est très pratique pour examiner le support de syntaxe et faire le premier pas vers le monde de PostgreSQL.
Vous pouvez déployer le projet IvorySQL-WASM localement en quelques étapes, en suivant le billet de blog publié par IvorySQL sur le sujet.
Sinon, vous pouvez essayer le WASM hébergé sur le site web d’IvorySQL.
Vous souhaitez en apprendre davantage sur l’utilisation d’IvorySQL ? Restez à l’affût des webinaires enregistrés sur leur site web (à venir !), ou consultez les enregistrements de la conférence HOW2025 à Jinan, en Chine, en attendant.
La prochaine conférence à Jinan est déjà prévue, du 26 au 28 avril ! (Au passage, l’appel à contributions est ouvert jusqu’au 27 février 2026.)
Notre équipe est heureuse d’employer des contributeurs au projet IvorySQL. Certains de nos membres (Cédric Villemain, Yasir Hussain Shah) ont été reconnus dans les notes de version de 5.0 et 5.1 — et nous avons d’autres ajouts prévus. Pour la prochaine version, nous avons prévu des développements passionnants, notamment :
ENABLE/DISABLEUTL_FILECREATE TRIGGER style Oracle (sans avoir besoin de créer une fonction au préalable)(+)Nous avons hâte de voir les résultats du travail communautaire en cours pour la prochaine version. De nombreuses fonctionnalités excellentes sont activement ajoutées ; par exemple, récemment, un nouveau contributeur au projet, Rophy Tsai, a ajouté les paquets DBMS_OUTPUT et DBMS_UTILITY : des éléments largement utilisés dans les bases de code SQL basées sur Oracle. Ils ont récemment été fusionnés dans la branche principale d’IvorySQL et seront probablement inclus dans la prochaine version mineure ou majeure.
Pour ceux qui souhaitent passer à PostgreSQL ou l’explorer sans modifications importantes de leur logique de base de données et de leurs applications existantes, IvorySQL (en particulier v5.x) offre une solution pratique. Une migration directe vers PostgreSQL pourrait, dans certains cas, nécessiter des changements importants tant au niveau des objets de base de données qu’au niveau du code applicatif. IvorySQL aide à combler cet écart, permettant une adoption plus fluide de PostgreSQL avec une plus grande compatibilité.
De plus en plus d’entreprises cherchent à se libérer des coûts et des contraintes d’Oracle en migrant vers PostgreSQL. Mais comment réussir cette transition sans y passer des mois ? Voici une méthode éprouvée, rapide et sécurisée, basée sur des retours d’expérience et des outils open source.
Avant de migrer, il est essentiel de faire l’état des lieux : lister les objets Oracle par une extraction complète (tables, vues, séquences, procédures, fonctions, packages).
Mais aussi avoir des échanges réguliers avec le client pour affiner les constats et valider les orientations, mais aussi d’identifier les dépendances (applications connectées avec quelle technologie, jobs, interfaces,…)
Et enfin, repérer les spécificités Oracle du client (fonctions spécifiques comme ROWID, DUAL, DBMS_XXX,…) et tout autre mot-clé demandant une attention particulière.
La réussite d’une transition vers PostgreSQL - car il s’agit bien d’une transition progressive et non d’une migration - repose autant sur la stratégie que sur les outils.
Il ne suffit pas de copier des objets : il faut comprendre les subtilités du moteur Oracle et les transposer intelligemment dans l’univers PostgreSQL.
Parmi les outils incontournables, Ora2Pg joue un rôle central. Il permet non seulement de générer des rapports d’inventaire clairs, mais aussi d’automatiser la conversion des schémas, des données et du code PL/SQL. C’est un accélérateur précieux pour les projets bien structurés.
Mais dans certains contextes, la réalité est plus complexe. De nombreux clients accumulent une dette technique importante, avec des milliers de lignes de code procédural. Tenter de tout réécrire en PL/pgSQL dans un délai court reviendrait à épuiser les équipes, tout en compromettant la migration elle-même. Maintenir deux bases de code — l’une en PL/SQL, l’autre en PL/pgSQL — pendant une phase de transition complète est souvent intenable sur le plan organisationnel.
C’est précisément là qu’IvorySQL offre une alternative puissante. Ce fork de PostgreSQL, enrichi de compatibilités Oracle (PL/SQL, ROWID, DUAL, etc.), permet de réduire considérablement le besoin de réécriture immédiate. En combinant IvorySQL avec une documentation ciblée et des scripts de validation métier, on obtient une transition plus rapide, plus fiable, et surtout mieux maîtrisée.
Une fois en production, les équipes disposent du temps nécessaire pour réécrire progressivement leur code procédural en PL/pgSQL, sans pression ni rupture fonctionnelle.
L’un des grands avantages d’IvorySQL, c’est qu’il réalise une partie de l’intégration en amont. Grâce à son support natif du PL/SQL, des objets Oracle et de la syntaxe Oracle-compatible, de nombreux éléments migrés via Ora2Pg fonctionnent immédiatement sans adaptation lourde.
Cela ne dispense évidemment pas d’une phase de test, bien au contraire : il est essentiel de valider les comportements métier dans un environnement de préproduction IvorySQL. Les procédures, fonctions, packages, triggers et vues doivent être testés avec des cas réels, en comparant les résultats entre Oracle et IvorySQL pour garantir l’équivalence fonctionnelle.
Des scripts de comparaison peuvent être utilisés pour vérifier les réponses aux requêtes, les effets des transactions, ou les comportements des fonctions migrées. Mais dans bien des cas, IvorySQL permet de réduire considérablement le besoin de patchs ou de réécriture, ce qui accélère la mise en production et sécurise la transition.
Une transition réussie ne se limite pas à la technique : elle repose aussi sur une documentation claire et un accompagnement adapté. Il est essentiel de rédiger des cahiers de tests entiers et exhaustifs par objet complexe et modules (procédure, package, trigger…), afin de garder une trace des choix techniques, des adaptations réalisées, et des points d’attention.
L’accompagnement des équipes client est tout aussi important. Des ateliers ciblés permettent de transmettre les bonnes pratiques, d’expliquer les différences entre Oracle et PostgreSQL, et de faciliter la prise en main d’IvorySQL.
Enfin, la réussite d’une transition vers PostgreSQL repose aussi sur l’accompagnement des équipes techniques et fonctionnelles. Des sessions de formation ciblées permettent aux développeurs, DBA et chefs de projet de s’approprier les spécificités d’IvorySQL, de comprendre les différences avec Oracle, et de monter en compétence rapidement.
Ce dispositif s’appuie également sur un support technique structuré, qui aide à résoudre les blocages, à sécuriser les choix d’implémentation, et à fluidifier les échanges entre les équipes projet et les experts migration.
Lors d’une mission récente pour une entreprise du secteur privé, nous avons accompagné la transition d’une base Oracle vers IvorySQL dans un contexte contraint : dette technique importante, volumétrie élevée, et délais serrés.
Grâce à IvorySQL et notre capacité à automatiser cette transition, cette transition s’est faite rapidement et la quasi totalité des objets ont été intégrés sans réécriture.
La bascule d’IvorySQL vers PostgreSQL peut s’effectuer sereinement, dans la mesure où l’application fonctionne pleinement et répond aux attentes métier.
Les équipes ont pu se concentrer sur les tests métier, tandis que la formation ciblée et le support technique ont permis une montée en compétence rapide.
Il est indispensable de réussir ce genre de projet pour emmagasiner de la confiance et développer cette opération sur la totalité de votre parc d’instances Oracle !
Vous envisagez une transition Oracle vers PostgreSQL ? Parlons-en.
Contactez notre équipe d’experts, à tout moment: contact@data-bene.io
Le 26 novembre 2025, IvorySQL 5.0 a été publié - voir l’annonce ici pour plus d’informations sur ce projet open source.
]]>