Pourquoi les entreprises quittent Oracle pour PostgreSQL (et comment le faire en toute sécurité)

TL;DR : La licence Oracle est devenue un fardeau financier important.
Un serveur double socket exécutant Oracle Enterprise Edition peut coûter plus de 350 000 € en licences de base seules, avec 22% de frais de support annuels qui augmentent chaque année.
PostgreSQL est désormais la base de données la plus utilisée par les développeurs, avec un taux d'adoption global de 55,6% et de 58,2% parmi les développeurs professionnels dans l'enquête Stack Overflow Developer Survey 2025, ainsi qu'une maturité éprouvée en entreprise.
Les entreprises qui ont effectué le changement rapportent des réductions de 70 à 80% sur les coûts de licence de base de données.
Ce post explique ce qui motive l'exode et ce qu'il faut pour migrer en toute sécurité.

Votre renouvellement de support Oracle arrive sur votre bureau.

Le nombre est plus élevé que l'année dernière.

Encore.

Tu te rebelles.

Oracle dit que c'est le prix.

Tu signes, car tu n'as pas le choix en ce moment.

Ce scénario se déroule chaque année dans des milliers de départements informatiques.

C'est la raison principale pour laquelle les entreprises évaluent désormais sérieusement la migration d'Oracle vers PostgreSQL en chiffres qui auraient été impensables il y a cinq ans.

Après 20 ans à gérer des environnements Oracle au sein d'entreprises telles qu'une grande banque européenne exploitant une infrastructure Exadata de 14 000 bases de données et une banque espagnole de premier plan gérant des environnements Oracle RAC 12c et 19c critiques, j'ai été témoin de cette évolution.

La question que mes clients me posent n'est plus “ devrions-nous migrer ? ”.

C'est “ quand, et comment le faire sans rien casser ? ”

Voici ce que vous devez savoir.

Pourquoi Oracle est-il soudainement si cher ?

Oracle Enterprise Edition coûte environ 43 000 € par licence processeur, plus 22 % de frais de support annuels qui s'accumulent chaque année.%.

Les modules complémentaires tels que RAC, le partitionnement et le pack de diagnostic multiplient le coût des déploiements entièrement configurés par deux ou trois par rapport au coût de base.

Oracle contrôle les prix par le biais de contrats négociés sous accord de non-divulgation — les clients n'ont aucun levier sur le prix final.

Un serveur Intel de base à double socket avec 16 cœurs coûte à lui seul 350 000 € en licences EE de base, avant toute option supplémentaire.

La plupart des entreprises qui exploitent des parcs Oracle en production paient pour plusieurs modules complémentaires sans le savoir.

Le Liste de prix des technologies Oracle est publique, mais les montants que les entreprises paient réellement sont négociés sous accord de confidentialité.

Oracle contrôle toute la conversation sur les prix.

C'est intentionnel.

PostgreSQL est-elle vraiment prête pour les charges de travail d'entreprise ?

Oui — et ce depuis plusieurs années.

PostgreSQL prend en charge les transactions ACID, le partitionnement, la réplication logique, la recherche en texte intégral, le JSON et les requêtes parallèles.

Selon le Enquête sur les développeurs Stack Overflow 2025, elle a un taux d'adoption global par les développeurs de 55,6% et de 58,2% parmi les développeurs professionnels — la base de données la plus utilisée par les développeurs pour la quatrième année consécutive.

Le Annonce de la sortie de PostgreSQL 17 indique que les charges de travail à forte concurrence peuvent bénéficier d'un débit d'écriture jusqu'à 2 fois supérieur grâce aux améliorations du traitement du WAL.

Trente ans de développement continu depuis le projet POSTGRES à l'UC Berkeley.

Un écosystème commercial qui comprend désormais EDB, Percona, Crunchy Data et Supabase, tous offrant un support d'entreprise, des outils de haute disponibilité et des services cloud gérés.

L'écart technique avec Oracle est réel mais gérable.

Ce n'est pas la technologie qui fait échouer les migrations.

Ce qui unit les équipes, c'est sous-estimer la complexité de la conversion PL/SQL et les dépendances au niveau de l'application.

Quelles entreprises réalisent réellement des économies

Le cas financier n'est plus théorique.

Chiffres réels issus d'études de cas publiées :

• Un opérateur télécom mondial a migré d'Oracle vers PostgreSQL et réduit les coûts de base de données de 70%, tout en divisant par deux les délais de déploiement.
• Une entreprise qui a migré une base de données Oracle de 10 To vu que les dépenses de licence ont diminué d'environ 80% sans aucune perturbation des activités.
• Une analyse a révélé un retour sur investissement (ROI) de 340% sur trois ans d'une migration Oracle vers PostgreSQL terminée, en tenant compte des coûts de migration, des outils, et de l'élimination totale des frais de licence et de support Oracle.

Le chiffre de 70–80% de réduction des coûts de licence revient constamment dans les études de cas.

Le principe est simple : PostgreSQL est gratuit.

Vous payez toujours pour l'infrastructure, les contrats de support (si vous en voulez), et la migration elle-même.

But the compounding 8–10% annual Oracle support increase stops.

Définitivement.

Quels sont les risques cachés d'un audit Oracle ?

Les audits Oracle ont lieu sur un cycle de 2 à 3 ans et trouvent régulièrement des options non autorisées — Diagnostics Pack, Tuning Pack, Partitioning — activées sans que personne ne réalise les implications de la licence.

Chacun déclenche des frais rétroactifs.

Les entreprises qui exécutent Oracle sur VMware sont exposées davantage : Oracle exige une licence pour chaque hôte physique d'un cluster VMware, quel que soit son utilisation réelle.

Les factures d'audit s'élèvent régulièrement à six ou sept chiffres.

Selon le Redressement de la conformité, Depuis 2024, la fréquence des audits d'Oracle a augmenté.

Les résultats sont rarement mineurs.

L'exposition VMware est particulièrement sous-estimée : un petit déploiement Oracle sur une grande ferme VMware peut générer une exposition de licence se chiffrant en millions d'euros.

Rester sur Oracle comporte son propre risque financier.

Plus vous restez longtemps, plus vous êtes susceptible de faire face à une facture d'audit qui éclipse le coût de la migration.

Si vous n'êtes pas sûr que votre environnement Oracle soit un bon candidat à la migration, je propose une évaluation à prix fixe qui répond exactement à cette question : registre des risques, score de complexité et projection réaliste des coûts/avantages. Voir le service d'évaluation →

La migration est-elle techniquement difficile ?

La migration d'Oracle vers PostgreSQL est techniquement complexe mais gérable.

Le déplacement des données n'est pas la partie difficile.

Les parties difficiles sont la conversion de PL/SQL vers PL/pgSQL, le mappage des types de données et les dépendances au niveau de l'application.

Des outils comme ora2pg automatisent 60 à 80% de la conversion de schéma — les 20 à 40% restants nécessitent une révision et une réécriture manuelles.

Oracle utilise des types de données (NUMBER, VARCHAR2, DATE, CLOB) qui ne correspondent pas directement aux équivalents PostgreSQL.

Les packages, les curseurs et la gestion des exceptions en PL/SQL doivent être réécrits, et pas seulement convertis.

Les procédures stockées qui dépendent d'un comportement spécifique à Oracle — coercition de type implicite, table DUAL, ROWNUM — nécessitent une gestion attentive.

ora2pg gère la majeure partie de la conversion de schéma automatiquement.

Il ne gère pas les cas limites.

La conversion de code est un domaine qui nécessite une connaissance approfondie des deux côtés.

À quoi ressemble réellement une migration sûre

Une migration sûre d'Oracle vers PostgreSQL suit cinq phases :

Phase 1 : Évaluation

Inventoriez vos schémas, procédures stockées, objets personnalisés et dépendances d'application.

C'est ici que se trouvent les surprises.

Une évaluation payante — généralement 3 jours — vous donne un devis de projet à prix fixe et un registre des risques réaliste avant que vous ne vous engagiez dans quoi que ce soit.

Phase 2 : Conversion du schéma et du code

Correspondance des types de données, conversion PL/SQL vers PL/pgSQL, séquences, partitionnement, déclencheurs et vues.

Des outils comme ora2pg automatisent 60 à 80% de cela.

Les 20–40% restants nécessitent une réécriture pratique.

Phase 3 : Migration des données

Chargement initial complet suivi d'une réplication continue à l'aide de CDC (Change Data Capture) pour maintenir la synchronisation de PostgreSQL pendant qu'Oracle reste en ligne.

AWS DMS gère cela très bien pour la plupart des environnements.

Phase 4 : Tests

Validation fonctionnelle ligne par ligne.

Comparaison des performances par rapport aux bases de référence Oracle.

Tests de régression d'application.

Cette phase prend plus de temps que ce que la plupart des équipes s'attendent.

Phase 5 : Basculement

Une fenêtre de maintenance planifiée — aussi courte que quelques minutes avec une stratégie de zéro temps d'arrêt — où le trafic bascule d'Oracle vers PostgreSQL.

Oracle est maintenu en fonctionnement mais figé pour une fenêtre de restauration, généralement de deux à quatre semaines.

Si un problème critique apparaît sur PostgreSQL, le trafic peut être redirigé vers Oracle — bien que toutes les données écrites sur PostgreSQL pendant cette période seraient perdues, la décision de revenir en arrière doit donc être rapide.

La chronologie s'étend de 3 semaines pour une petite base de données avec un minimum de PL/SQL à 3 mois pour un environnement de complexité moyenne.

Les grands parcs Oracle lourdement personnalisés nécessitent un exercice d'évaluation personnalisé avant de s'engager sur un calendrier.

En résumé

Les coûts des licences Oracle augmentent chaque année.

Les audits sont de plus en plus fréquents et sévères.

PostgreSQL a atteint un niveau de maturité d'entreprise qui en fait un remplacement crédible pour la plupart des charges de travail Oracle.

Les entreprises qui ont effectué la transition signalent des réductions de 70 à 80% dans les dépenses de licences de bases de données.

Trois choses à retenir de ce message :

• L'argument financier en faveur de la migration d'Oracle vers PostgreSQL est solide et devient de plus en plus solide à chaque augmentation de prix d'Oracle.
• PostgreSQL est prêt pour la production. Le risque réside dans la manière dont vous exécutez la migration, pas dans la technologie elle-même.
• La conversion PL/SQL et les dépendances d'application sont les parties difficiles. Le déplacement des données ne l'est pas.

Si vous évaluez une migration d'Oracle vers PostgreSQL, la première étape appropriée est une évaluation du périmètre.

Contactez-moi à rootfan.com pour un appel gratuit de 30 minutes afin de discuter de votre environnement.

Aucune offre commerciale — juste une conversation technique pour savoir si la migration est pertinente pour votre situation.

Foire aux questions