Comparatif des SGBD relationnels : bien choisir sa base de données
Dès qu’un projet manipule des données structurées — clients, commandes, produits, utilisateurs — la question du système de gestion de base de données (SGBD) se pose. Et le choix est vaste : MySQL, PostgreSQL, MariaDB, SQLite du côté open source, Oracle, SQL Server et Db2 du côté commercial. Chacun a ses forces, ses faiblesses et son terrain de prédilection.
Ce comparatif passe en revue les principaux SGBD relationnels du marché, avec les critères qui comptent vraiment au moment de choisir. L’objectif n’est pas de désigner un « meilleur » SGBD dans l’absolu — il n’existe pas — mais de comprendre lequel convient à quel usage.
Qu’est-ce qu’un SGBD relationnel ?
Un SGBD relationnel (ou SGBDR) organise les données en tables reliées entre elles, un peu comme des feuilles de calcul qui peuvent se référencer mutuellement. On y accède avec le langage SQL (Structured Query Language), une norme commune à tous ces systèmes — ce qui explique qu’on retrouve des requêtes très proches d’un SGBD à l’autre.
Le modèle relationnel repose sur quelques principes solides, dont les fameuses propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité) qui garantissent la fiabilité des transactions : soit une opération se fait entièrement, soit pas du tout, sans jamais laisser les données dans un état incohérent. C’est ce qui rend ces systèmes fiables pour des usages critiques comme la banque ou la comptabilité.
Tous les SGBD présentés ici sont relationnels et parlent SQL. Leurs différences tiennent à leur architecture, leurs performances selon les usages, leur richesse fonctionnelle, leur licence et leur coût.
Les SGBD open source
MySQL
MySQL est probablement le SGBD le plus connu, notamment parce qu’il est le moteur historique de l’écosystème web (les fameuses architectures LAMP, et des CMS comme WordPress, Drupal ou Magento). Créé en 1995, il a été racheté par Sun puis par Oracle en 2010.
Ses atouts : simple à prendre en main, très largement documenté, supporté par la quasi-totalité des hébergeurs, et rapide sur les opérations de lecture simples. C’est souvent le choix par défaut pour un site web classique.
Ses limites : il suit moins strictement le standard SQL que d’autres, et montre ses faiblesses sur les requêtes très complexes, les jointures massives ou les traitements analytiques poussés. Sur le plan de la licence, MySQL utilise un double modèle : une édition communautaire gratuite sous licence GPL, et une licence commerciale payante vendue par Oracle pour les entreprises qui intègrent MySQL dans un produit distribué. La propriété d’Oracle reste par ailleurs un sujet de méfiance pour une partie de la communauté — c’est précisément ce qui a donné naissance à MariaDB.
PostgreSQL
PostgreSQL (souvent abrégé « Postgres ») est le SGBD open source qui monte, au point de devenir la référence pour beaucoup de nouveaux projets. Ses origines remontent à un projet universitaire de Berkeley dans les années 1980 ; il est publié sous son nom actuel depuis 1996.
Ses forces sont nombreuses : une conformité au standard SQL parmi les meilleures, une grande rigueur sur l’intégrité des données, et une extensibilité remarquable. Il gère nativement des types de données avancés (JSON via JSONB, tableaux, types géographiques, types personnalisés) et dispose d’un riche écosystème d’extensions — PostGIS pour les données géographiques, ou des modules récents pour la recherche vectorielle utilisée en intelligence artificielle. Sur les requêtes complexes, les jointures et les charges analytiques, il est généralement plus performant que MySQL.
Un atout majeur pour les projets à long terme : PostgreSQL est développé par une communauté mondiale sans propriétaire unique, sous une licence permissive (proche des licences BSD/MIT). Aucune entreprise ne peut le racheter ou en changer les conditions, ce qui écarte tout risque de dépendance à un éditeur (le fameux « vendor lock-in »). Sa contrepartie : une courbe d’apprentissage un peu plus exigeante que MySQL, et un outillage graphique de premier niveau historiquement moins abouti (même s’il a beaucoup progressé).
MariaDB
MariaDB est né en 2009, créé par le fondateur original de MySQL en réaction au rachat par Oracle. C’est un fork (une dérivation) de MySQL, conçu pour rester pleinement open source et gouverné par la communauté.
Longtemps, MariaDB a été un remplaçant quasi direct de MySQL (« drop-in replacement ») : on pouvait passer de l’un à l’autre sans quasiment rien changer. Au fil des versions, les deux ont toutefois divergé, et cette compatibilité n’est plus totale sur les versions récentes. MariaDB apporte ses propres moteurs de stockage et fonctionnalités (comme ColumnStore, orienté analyse de données). Sa licence est clairement open source (GPL/LGPL), sans le volet commercial de MySQL — ce qui rassure ceux que la gouvernance Oracle inquiète.
SQLite
SQLite joue dans une catégorie à part. Ce n’est pas un serveur de base de données comme les autres : c’est une base embarquée, contenue dans un simple fichier, sans serveur à installer ni à administrer. La base « vit » directement dans l’application qui l’utilise.
C’est le choix idéal pour les applications mobiles, les logiciels de bureau, les petits sites, ou tout ce qui a besoin de stocker des données localement sans la lourdeur d’un serveur. SQLite est extrêmement léger, fiable, et libre de droits. Sa limite est le revers de sa force : conçu pour un accès local et un nombre limité d’écritures simultanées, il n’est pas adapté aux applications à fort trafic avec de nombreux utilisateurs écrivant en même temps. Pour ce type de besoin, il faut un vrai serveur comme les précédents.
Les SGBD commerciaux
Oracle Database
Oracle Database est la référence historique des bases de données d’entreprise critiques : banque, assurance, santé, logistique. Sa réputation repose sur des performances élevées sur les charges transactionnelles extrêmes, une très haute disponibilité (via des technologies comme Real Application Clusters), et une robustesse éprouvée depuis des décennies.
Son principal frein est le coût. Les licences Oracle sont parmi les plus chères du marché — plusieurs dizaines de milliers d’euros par processeur, auxquels s’ajoutent la maintenance annuelle, l’infrastructure et des administrateurs spécialisés. Pour une grande entreprise aux besoins critiques, l’investissement se justifie ; pour un projet plus modeste, il est disproportionné. C’est d’ailleurs ce coût qui pousse de nombreuses organisations à migrer vers PostgreSQL, dont le comportement est réputé proche d’Oracle.
Microsoft SQL Server
SQL Server est le SGBD de Microsoft, très présent dans les environnements d’entreprise, en particulier ceux déjà bâtis autour des technologies Microsoft. Il utilise un dialecte SQL propre appelé T-SQL (Transact-SQL) et se distingue par un outillage particulièrement soigné — son environnement d’administration est souvent cité comme l’un des meilleurs de sa catégorie.
Il s’intègre parfaitement à l’écosystème Microsoft (services décisionnels, cloud Azure), ce qui en fait un choix naturel pour les organisations qui y sont déjà investies. Comme Oracle, c’est un produit commercial dont les licences ont un coût, même s’il propose des éditions plus accessibles, dont une version gratuite limitée pour les petits besoins. Son terrain de prédilection reste les entreprises établies, la finance, la santé et le secteur public.
IBM Db2
Db2 est le SGBD relationnel d’IBM, incontournable dès qu’on entre dans le monde des grands systèmes bancaires et assurantiels. Il existe en plusieurs variantes, dont la plus emblématique est Db2 for z/OS, la version qui tourne sur les mainframes IBM. C’est là qu’il règne : sur ces environnements, il équipe la quasi-totalité des installations, en tandem avec des applications historiques souvent écrites en COBOL.
Db2 est réputé pour sa fiabilité et sa performance sur les charges transactionnelles massives — le traitement de millions d’opérations financières avec une disponibilité extrême. Comme Oracle et SQL Server, c’est un produit propriétaire, à la tarification calculée selon la capacité du système. Il existe aussi une version pour les serveurs Linux, Unix et Windows (Db2 LUW), mais c’est bien sur mainframe que Db2 occupe une place à part, au cœur d’infrastructures critiques que les banques et assurances maintiennent depuis des décennies. Discret pour le grand public, il n’en reste pas moins l’un des piliers du transactionnel d’entreprise.
Tableau comparatif
| SGBD | Type | Licence | Idéal pour |
|---|---|---|---|
| MySQL | Open source (Oracle) | GPL + commerciale | Sites web, CMS, LAMP |
| PostgreSQL | Open source (communauté) | Permissive (BSD/MIT) | Projets modernes, données complexes, analytique |
| MariaDB | Open source (communauté) | GPL/LGPL | Alternative à MySQL sans Oracle |
| SQLite | Open source | Domaine public | Mobile, bureau, embarqué, petits projets |
| Oracle Database | Commercial | Propriétaire (coûteuse) | Grandes entreprises, systèmes critiques |
| SQL Server | Commercial | Propriétaire | Environnements Microsoft, entreprises |
| IBM Db2 | Commercial | Propriétaire | Mainframe, banque, assurance, COBOL |
Comment choisir ? Quelques repères
Plutôt qu’un gagnant unique, voici des repères selon le contexte.
Pour un site web ou un blog (WordPress et consorts), MySQL ou MariaDB sont les choix naturels : simples, parfaitement supportés par les hébergeurs, et amplement suffisants. MariaDB si vous préférez éviter la gouvernance Oracle.
Pour une nouvelle application moderne, surtout si elle manipule des données complexes, du JSON, des données géographiques, ou nécessite des requêtes analytiques, PostgreSQL est aujourd’hui le choix par défaut le plus solide. C’est aussi un pari sûr sur le long terme grâce à sa licence et sa gouvernance.
Pour une application mobile ou de bureau, ou tout besoin de stockage local léger, SQLite est imbattable de simplicité.
Pour une grande entreprise aux besoins critiques, avec de très gros volumes, des exigences de disponibilité extrêmes et un budget en conséquence, Oracle, SQL Server ou Db2 ont leur place — SQL Server étant particulièrement pertinent dans un environnement déjà Microsoft, et Db2 dans le monde mainframe (banque, assurance), souvent aux côtés d’applications COBOL.
Trois critères résument souvent la décision : le budget (open source gratuit vs licences commerciales), la volumétrie et la criticité (un petit site n’a pas les mêmes besoins qu’une banque), et les compétences déjà présentes dans l’équipe (le SGBD que vos développeurs maîtrisent déjà a une vraie valeur).
En résumé
Il n’y a pas de meilleur SGBD relationnel, seulement celui qui correspond à votre projet :
- MySQL / MariaDB : la valeur sûre du web, simples et bien supportés ;
- PostgreSQL : le plus complet et le plus rigoureux, idéal pour les projets modernes et les données complexes ;
- SQLite : imbattable pour l’embarqué et les petits besoins locaux ;
- Oracle / SQL Server / Db2 : les poids lourds commerciaux pour les grandes entreprises, avec le coût correspondant — Db2 régnant sur le mainframe bancaire.
Le bon réflexe est de partir de votre besoin réel plutôt que de la réputation d’un produit : la volumétrie attendue, la complexité des données, le budget, et les compétences de votre équipe. Un SGBD surdimensionné coûte cher inutilement ; un SGBD sous-dimensionné se paie en performances et en migrations pénibles. Le bon choix est celui qui est juste assez puissant pour ce que vous en faites.
Vous hésitez entre deux SGBD pour un projet précis ? Le duel le plus fréquent aujourd’hui oppose MySQL et PostgreSQL — un sujet qui mérite à lui seul qu’on s’y attarde, tant les deux ont évolué ces dernières années.