Dans un contexte où les organisations cherchent à réduire leur dépendance aux solutions propriétaires et à optimiser leurs coûts, PostgreSQL s’impose comme une alternative sérieuse et robuste à Oracle. Mais si l’idée de migrer semble séduisante, la mise en œuvre est souvent bien plus complexe que prévu. Entre différences de langage, types de données, performance, et gouvernance, la transition Oracle vers PostgreSQL est un véritable projet d’ingénierie.

Analyse préalable : la cartographie de l’existant

Avant toute action, il est impératif de cartographier l’existant :

• Schéma de données : nombre de tables, vues, contraintes, triggers.

• Code stocké : nombre de procédures, fonctions, packages.

• Données volumineuses : présence de LOBs, partitions, tables historiques.

• Interactions applicatives : clients connectés, middlewares, jobs CRON, batchs.

• Composants spécifiques Oracle : Materialized Views, Packages DBMS, Synonyms, Grants avancés.

Complexités syntaxiques et fonctionnelles 

1. PL/SQL vs PL/pgSQL : des similitudes trompeuses

PL/pgSQL est plus limité que PL/SQL sur plusieurs points :

2. Gestion des packages

Les packages Oracle permettent d’encapsuler des fonctions/procédures et des variables globales. PostgreSQL ne supporte pas les packages nativement, ce qui oblige à :

• Réécrire chaque fonction individuellement.

• Utiliser des schemas dédiés pour simuler une logique d’encapsulation.

3. Types de données : attention aux pièges

PostgreSQL ne supporte pas LONG, LONG RAW. Ces colonnes nécessitent une refonte.

4. Structures avancées Oracle à remplacer

5. Performance et tuning : deux mondes différents

Oracle :

• CBO (Cost-Based Optimizer) très mature

• Historiques d’exécution (AWR)

• Index bitmap, index cluster

• Hints (/*+ INDEX(table col) */)

PostgreSQL :

• Moins de hints, tout repose sur les statistiques à jour

• Optimisation parfois moins fine pour les requêtes complexes

• Explain Analyze : outil de base

• Absence de parallel execution automatique (introduit partiellement à partir de PG 13)

6. Transfert des données : volumétrie et fiabilité

• Dump logique : avec pgloader, ou exports CSV.

• Dump physique impossible (formats différents).

• Problèmes rencontrés :

  • Encodage (UTF-8 vs WE8MSWIN1252)

  • Données invalides (dates 0000, caractères spéciaux)

  • LOBs incomplets

7. Sécurité, audit, et gouvernance

Oracle propose une gestion très fine des accès :

• Rôles hiérarchisés

• Profil utilisateur, expiration, complexité de mot de passe

• Audits avancés (FGA, SYSDBA logging)

PostgreSQL est plus simple mais peut être étendu :

• Extensions comme pgaudit, pgcrypto, ldapauth.

• Rôles simples, mais pas de hiérarchie native (à simuler).

• Pas de gestion native des profils utilisateurs avancés.

Stratégie de migration recommandée 

Principes clés avant de démarrer

1. Ne jamais sous-estimer la complexité (surtout pour le code stocké).

2. Impliquer les métiers et les équipes applicatives dès le départ.

3. Automatiser tout ce qui peut l’être (migration, tests, déploiements).

4. Favoriser les migrations progressives si l’architecture le permet.

a. Phases à respecter :

1. Audit et évaluation de compatibilité

2. PoC sur une application pilote

3. Migration schéma + données

4. Tests fonctionnels et performance

5. Réécriture du code PL/SQL

6. Tests de non-régression

7. Bascule progressive ou big bang ( des analyses approfondies )

b. Approche Zero Downtime (ZDM)

• Capture de changements (CDC) via outils comme Debezium, Oracle GoldenGate, Striim.

• Synchronisation continue avant bascule.

Retour d’expérience : ce qu’on ne vous dit pas  

Migrer d’Oracle vers PostgreSQL est bien plus qu’un simple transfert technologique : c’est un changement de culture, un projet de transformation, et parfois un champ de mines si l’on ne s’y prépare pas correctement. Voici ce que la réalité du terrain enseigne … des détails que beaucoup découvrent… trop tard.

1. Le piège des packages PL/SQL

« On pensait que la majorité de notre logique métier était dans l’application. En fait, tout était dans des packages Oracle de 5 000 lignes… »

• Le problème : PostgreSQL ne gère pas les packages, alors qu’en Oracle, ils sont très utilisés pour structurer le code métier.

• Il faut démanteler les packages et réécrire chaque procédure/fonction dans un fichier séparé.

• Certaines variables globales doivent être simulées via des tables techniques ou des contextes utilisateurs.

• Le temps de migration du code PL/SQL est souvent sous-estimé : certains projets estiment à 60–70% de l’effort total rien que pour ça.

2. Le coût caché du refactoring applicatif

« On a migré la base. Mais 20% des requêtes SQL de l’appli plantaient, silencieusement. »

• Les applications sont souvent bardées de requêtes SQL en dur (parfois générées dynamiquement), dépendantes de comportements Oracle :

  • NULL ≠ ''

  • Comparaison implicite de types (TO_CHAR vs CAST)

  • Gestion des DUAL, ROWNUM, SYSDATE

  • Syntaxes comme CONNECT BY, MODEL, MERGE

• Les frameworks comme Hibernate ou JPA ajoutent une couche de complexité.

• Résultat : des bugs silencieux ou des comportements inattendus en production.

3. Manque de compétences PostgreSQL internes

• Le SGBD est différent dans sa philosophie, ses outils, et son mode de tuning :

  • PostgreSQL favorise l’ouverture (fichiers de conf, logs simples, monitoring via extensions).

  • Moins d’outils “automagiques” comme Oracle Enterprise Manager.

  • Plus besoin de “DBA-architectes” que d’“administrateurs système”.

• Le manque de compétence PostgreSQL ralentit les résolutions d’incidents, car les équipes doivent tout réapprendre : configuration, sécurité, extensions, syntaxe.

4. Les outils de migration ne font pas tout (vraiment)

• Les outils comme Ora2Pg, SCT ou pgloader sont utiles, mais :

  • Ne comprennent pas la logique métier (ex : IF v_status = 'P' THEN…).

  • N’interprètent pas les comportements implicites Oracle.

  • Génèrent parfois du code « syntaxiquement correct mais fonctionnellement faux ».

• La partie « conversion automatique » peut masquer une dette technique future énorme si le code est intégré sans relecture humaine.

5. Changement de comportement des plans d’exécution

« On avait une requête qui prenait 200 ms sous Oracle. Sur PostgreSQL, elle explosait à 20 secondes. »

• PostgreSQL a un optimiseur moins agressif, basé uniquement sur des statistiques.

• Il ne refait jamais automatiquement les plans (pas d’équivalent à Oracle Dynamic Sampling).

• Des requêtes complexes avec des JOIN, des WITH RECURSIVE, ou des UNION peuvent être mal optimisées si les statistiques ne sont pas à jour.

6. L’infrastructure autour doit aussi évoluer

« On pensait ne migrer que la base. En fait, tout notre écosystème a dû suivre… »

• PostgreSQL implique souvent :

  • Un nouveau système de monitoring (Grafana, Prometheus, pg_stat_statements)

  • Des outils de backup adaptés (pgBackRest, Barman, WAL-G)

  • Une gestion du clustering spécifique (Patroni, repmgr, etcd)

  • Des outils de CI/CD pour la gestion des migrations de schéma (Flyway, Liquibase)

En résumé

Vous avez un besoin d’un audit de votre environnement Oracle, d’une estimation de complexité ou d’un accompagnement personnalisé dans votre migration vers PostgreSQL ?

N’hésitez pas à nous contacter à  contact@dbaccompany.com nos experts vous aideront à sécuriser votre transition, éviter les pièges classiques, et tirer le meilleur de l’écosystème PostgreSQL.