Migrer d'Oracle vers PostgreSQL

SECTION 1

Pourquoi migrer d'Oracle vers PostgreSQL en 2026

En 2026, la question n'est plus de savoir si PostgreSQL est prêt pour la production critique, mais quand engager la bascule. Les hausses répétées des coûts de licence Oracle, des audits de conformité de plus en plus fréquents et l'inclusion progressive de fonctionnalités autrefois gratuites dans des options payantes poussent de nombreuses directions techniques à documenter une trajectoire de sortie. En face, PostgreSQL a gagné en maturité : les versions récentes comblent l'essentiel des écarts fonctionnels historiques, partitionnement natif, réplication logique, parallélisme des requêtes, et l'écosystème d'offres managées (Amazon Aurora PostgreSQL, Google AlloyDB, Azure Database for PostgreSQL Flexible Server, ou des acteurs spécialisés comme Crunchy Data et EDB) réduit fortement l'effort d'exploitation.

Trois motivations reviennent systématiquement dans les projets de migration. La réduction des coûts d'abord : PostgreSQL est open source et gratuit à l'installation, alors qu'Oracle facture séparément le partitionnement, la haute disponibilité (RAC, Data Guard) ou les fonctionnalités de diagnostic. La flexibilité ensuite : PostgreSQL s'intègre nativement avec tous les grands fournisseurs cloud, ce qui évite l'enfermement propriétaire et facilite les architectures multi-cloud ou hybrides. La personnalisation enfin : l'écosystème d'extensions PostgreSQL, pgvector pour la recherche vectorielle et les cas d'usage IA, PostGIS pour la géospatiale, TimescaleDB pour les séries temporelles, permet d'enrichir la base sans payer de licence complémentaire.

Mais une migration Oracle vers PostgreSQL ne se résume jamais à un export-import. Elle touche le schéma, le code métier embarqué dans la base, les habitudes d'exploitation et parfois l'architecture applicative elle-même. D'où la nécessité d'une méthode en phases, que nous détaillons dans les sections suivantes.

SECTION 2

Le vrai coût total de possession : Oracle face à PostgreSQL

Avant même de lancer un projet technique, il vaut mieux chiffrer précisément ce que coûte réellement le statu quo. Le calcul dépasse largement le prix affiché de la licence.

### Licences, options et support Oracle

Le modèle de licence Oracle Database Enterprise Edition se facture par cœur de processeur, avec un facteur multiplicateur selon l'architecture matérielle. À ce socle s'ajoutent des options vendues séparément : Partitioning, Real Application Clusters (RAC), Active Data Guard, Advanced Security, Diagnostics et Tuning Pack. Le support annuel représente généralement autour de 22 % du prix de licence, reconduit chaque année sans négociation possible. L'évolution du modèle de licensing Java SE, désormais calculé par employé et non plus par installation, a par ailleurs fait grimper la facture de nombreuses organisations sans changement de périmètre applicatif. Les audits de conformité, redoutés des DSI, ajoutent un risque financier difficile à budgéter à l'avance.

### Le TCO réel de PostgreSQL managé

PostgreSQL lui-même est gratuit, mais le TCO réel intègre l'infrastructure, l'éventuel support d'un éditeur spécialisé (EDB, Crunchy Data, Percona) ou l'abonnement à un service managé, ainsi que la montée en compétence des équipes. Les retours de projets de migration menés ces dernières années font état d'une réduction du TCO sur cinq ans comprise entre 40 % et 70 % selon la densité d'options Oracle utilisées au départ. L'écart est d'autant plus marqué que l'organisation exploitait des options RAC ou Active Data Guard, dont les équivalents PostgreSQL, réplication streaming, Patroni, extensions de clustering, restent open source.

SECTION 3

Phase 1 : évaluation et cartographie des dépendances applicatives

La première phase consiste à mesurer objectivement la complexité du chantier avant de s'engager. Il s'agit d'inventorier le patrimoine applicatif : nombre de schémas, volumétrie, requêtes PL/SQL, packages, triggers, jobs planifiés via DBMS_SCHEDULER, liens dblink vers d'autres bases, et usage de fonctionnalités propriétaires comme les requêtes hiérarchiques CONNECT BY, l'instruction MERGE ou les fonctions analytiques avancées. Chaque élément propriétaire identifié représente un point de conversion potentiellement coûteux.

Des outils d'assessment automatisent une bonne partie de ce travail. Le rapport d'ora2pg, généré via son option d'audit, évalue la compatibilité globale et estime en jours-homme l'effort de conversion du code métier. Les outils de conversion de schéma proposés par les fournisseurs cloud complètent cette analyse pour les architectures visant un hébergement managé. Le livrable de cette phase est un score de complexité par application, qui sert à prioriser l'ordre des migrations plutôt que de tout basculer d'un bloc.

SECTION 4

Phase 2 : conception du schéma cible et conversion du code métier

### Schémas, rôles et tablespaces

Première différence structurante : dans Oracle, un schéma est indissociable d'un utilisateur, alors que dans PostgreSQL, les schémas sont des espaces de noms indépendants des rôles, ce qui autorise des organisations plus fines. Il faut également revoir la stratégie de tablespaces, la casse des identifiants, PostgreSQL replie par défaut les noms non guillemetés en minuscules, contrairement à Oracle qui les met en majuscules, et les conventions de nommage pour éviter les ambiguïtés une fois la conversion réalisée.

### Convertir PL/SQL en PL/pgSQL

Le code métier embarqué demande le travail le plus minutieux. Les types NUMBER deviennent des numeric, VARCHAR2 des varchar ou text, DATE des timestamp. Les packages Oracle n'ont pas d'équivalent direct et se traduisent généralement en un schéma dédié regroupant des fonctions PL/pgSQL. Les curseurs, les exceptions, les attributs %ROWTYPE ont des équivalents proches mais pas identiques en syntaxe. L'extension Orafce comble une partie des écarts en réimplémentant des fonctions Oracle courantes, DECODE, fonctions de manipulation de dates, directement utilisables dans PostgreSQL, ce qui limite la réécriture manuelle.

### Les outils : ora2pg, pgloader, Ora_migrator

Plusieurs outils se complètent selon la nature du chantier. Ora_migrator, construit sur l'extension postgres_fdw, permet une conversion pilotée entièrement en SQL depuis PostgreSQL, pratique pour les équipes qui maîtrisent mieux l'écosystème cible. Ora2pg reste la référence open source pour extraire à la fois le schéma, les données et le code PL/SQL en un seul passage. Pgloader accélère le chargement des données une fois le schéma en place. Pour les migrations vers un hébergement cloud managé, les services de réplication de type Database Migration Service embarquent nativement la capture de changements, ce qui simplifie la coordination entre la conversion du schéma et la synchronisation des données.

SECTION 5

Phase 3 et 4 : tests de configuration et de performance

### Tests fonctionnels et non-régression

Le test de configuration consiste à charger un jeu de données identique dans les deux bases puis à exécuter les mêmes traitements fonctionnels pour comparer les résultats champ à champ. Les écarts détectés à ce stade, arrondis numériques différents, comportement des valeurs NULL dans les agrégations, tri des chaînes selon la locale, sont bien moins coûteux à corriger ici qu'après la bascule en production. Des scripts de diff automatisés, voire des frameworks de tests de données, industrialisent cette comparaison sur des volumes importants.

### Tuning et tests de charge

Le test de performance s'attaque ensuite aux différences de comportement entre les deux moteurs. L'optimiseur PostgreSQL raisonne différemment de l'optimiseur à base de coûts d'Oracle ; les statistiques doivent être régénérées avec ANALYZE, les types d'index adaptés (B-tree, GIN pour le texte ou le JSON, BRIN pour les grandes tables triées), et les paramètres de mémoire (shared_buffers, work_mem, effective_cache_size) dimensionnés pour la charge réelle. Des outils comme pgbench ou HammerDB permettent de rejouer des scénarios de charge représentatifs et de valider que les temps de réponse restent acceptables avant le cutover définitif.

SECTION 6

Phase 5 : stratégies de migration des données

### Snapshot et snapshot parallèle

Pour les bases de taille modeste, un snapshot complet, un export puis un import en une seule fenêtre de maintenance, reste l'approche la plus simple. Sur des volumes plus importants, le snapshot en parallèle découpe la migration en lots traités simultanément, généralement table par table ou par plage de clés, ce qui réduit d'autant la durée de la fenêtre de coupure nécessaire.

### Réplication logique et change data capture

Lorsque l'interruption de service doit être minimisée, la capture de changements (change data capture) prend le relais. Le principe : une réplication continue propage en quasi temps réel les modifications survenues côté Oracle vers la base PostgreSQL cible, pendant que l'ancienne base continue de servir la production. Le cutover final se résume alors à un basculement de chaîne de connexion une fois les deux bases synchronisées, ce qui ramène l'indisponibilité perçue à quelques minutes. Ce choix implique de sélectionner tôt la cible d'hébergement, car les mécanismes de CDC diffèrent selon qu'il s'agit d'un PostgreSQL auto-hébergé ou d'un service managé.

@cite:database-as-a-service-dbaas

SECTION 7

Haute disponibilité et exploitation post-bascule

La migration ne s'arrête pas au cutover. Une fois la production basculée, il faut reconstruire les mécanismes de résilience qu'Oracle offrait via RAC ou Active Data Guard : réplication streaming synchrone ou asynchrone, bascule automatique avec des outils comme Patroni, mise en pool des connexions avec PgBouncer pour absorber la charge, et sauvegardes avec restauration à un point dans le temps via pgBackRest ou Barman.

@cite:patterns-haute-disponibilite-postgresql

Le tuning ne se fait pas non plus en une fois. Les premières semaines en production révèlent souvent des requêtes qui se comportaient bien sous Oracle mais nécessitent un index ou une réécriture sous PostgreSQL. Un cycle d'observation continue, appuyé sur pg_stat_statements et des tableaux de bord de supervision, permet d'ajuster la configuration au fil de l'eau plutôt que de tout figer au moment du go-live.

@cite:postgresql-bonnes-pratiques-de-performance

SECTION 8

L'approche Adservio : piloter la migration comme un projet, pas une copie

Chez Adservio, nous abordons une migration Oracle vers PostgreSQL comme un projet à part entière, jamais comme une simple copie de données. Elle est réputée longue et coûteuse : c'est précisément pourquoi la phase d'évaluation et la planification en amont sont déterminantes, notamment pour éviter de recopier des données historiques dont l'utilité réelle en production est nulle.

Notre conviction : une migration réussie se prépare phase après phase, en tenant compte des différences réelles entre les deux systèmes plutôt qu'en cherchant un équivalent mécanique à chaque fonctionnalité Oracle. Nous accompagnons vos équipes tout au long de la démarche, évaluation, conversion, tests, bascule, exploitation, et leur transférons la maîtrise technique pour qu'elles exploitent durablement leur nouvelle base PostgreSQL en autonomie.

FAQ

Questions fréquentes