Module 2 — Comparatif : PostgreSQL, MySQL, MariaDB, MongoDB, SQL Server, SQLite, Redis
Bonne lecture et bon apprentissage ! Junior TSAFACK – 13/09/2026 Temps de lecture estimé : 10 minutes
Pourquoi ce choix compte autant
Section titled “Pourquoi ce choix compte autant”Choisir une base de données est une décision technique dont les conséquences durent des années — en changer en cours de route est rarement un simple remplacement, c’est souvent une réécriture partielle de l’application. Le bon choix dépend des besoins du projet, de son architecture, et de la façon dont il est censé évoluer — jamais d’une mode du moment.
Sept systèmes reviennent dans presque toutes les discussions techniques : PostgreSQL, MySQL, MariaDB, MongoDB, SQL Server, SQLite et Redis. En connaître les différences réelles évite de choisir par réflexe ce qu’on connaît déjà, plutôt que ce qui convient au problème posé.
Le tableau comparatif
Section titled “Le tableau comparatif”| Système | Type | Licence | Points forts | Limites à connaître |
|---|---|---|---|---|
| PostgreSQL | Relationnel (+ extensions multi-modèle) | PostgreSQL License (permissive) | Extensibilité (JSONB, pgvector…), conformité SQL stricte, aucune restriction d’usage commercial |
Un peu plus exigeant à régler finement (tuning) que MySQL par défaut |
| MySQL | Relationnel | GPL v2 (communautaire) + licence commerciale (Oracle) | Immense écosystème, très répandu (WordPress, la majorité des hébergements mutualisés) | Propriété d’Oracle — certaines fonctionnalités avancées réservées à l’édition Enterprise |
| MariaDB | Relationnel | GPL v2 | Fork communautaire de MySQL né après le rachat de Sun/MySQL par Oracle (2009), garanti 100% libre | Compatible MySQL mais diverge peu à peu (certaines fonctionnalités ne sont plus interchangeables) |
| MongoDB | Document | SSPL (non reconnue « open source » par l’OSI) | Schéma flexible, mise à l’échelle horizontale native (sharding), très adapté aux catalogues hétérogènes | La SSPL impose que tout service public basé sur MongoDB republie son infrastructure sous la même licence — un vrai frein pour certains hébergeurs cloud |
| SQL Server | Relationnel | Propriétaire (Microsoft) | Intégration profonde à l’écosystème Microsoft (.NET, Azure, Power BI) | Coût de licence significatif au-delà de l’édition Express (limitée en taille de base) |
| SQLite | Relationnel, embarqué | Domaine public | Aucun serveur à administrer — toute la base tient dans un seul fichier ; embarqué dans des milliards d’appareils (chaque navigateur, chaque téléphone Android/iOS) | Pas conçu pour des écritures concurrentes à haut volume — un seul processus écrit à la fois |
| Redis | Clé-valeur (+ structures avancées) | AGPL v3 (depuis Redis 8, 2025) | Vitesse en mémoire, structures de données riches (listes, sets, streams), quasi-standard pour le cache | Voir l’encadré ci-dessous : son historique de licence a été mouvementé |
Un vrai rebondissement à connaître : l’histoire de la licence Redis
Section titled “Un vrai rebondissement à connaître : l’histoire de la licence Redis”Ce n’est pas un détail anecdotique — c’est un cas d’école sur les risques réels d’une dépendance à un logiciel open source :
- Jusqu’en mars 2024 : Redis était sous licence BSD-3-Clause, permissive et sans restriction.
- Mars 2024 : Redis Ltd. passe à une double licence SSPL / RSALv2 (Redis Source Available License) — ni l’une ni l’autre reconnue « open source » par l’OSI (Open Source Initiative). Réaction immédiate de la communauté : plusieurs forks entièrement libres apparaissent (notamment Valkey, porté par la Linux Foundation avec le soutien d’AWS, Google et d’autres).
- Mai 2025 (Redis 8) : Redis Ltd. revient en arrière et publie Redis sous licence AGPL v3, une licence open source reconnue par l’OSI — un choix rare pour une entreprise de faire marche arrière publiquement après une décision aussi commentée.
La leçon à en tirer, au-delà de Redis lui-même : la licence d’un logiciel n’est pas un détail juridique périphérique — elle peut changer en cours de route, avec un impact réel sur ce qu’une entreprise a le droit de faire avec (héberger un service payant basé dessus, par exemple). Vérifier la licence actuelle avant un choix d’architecture, et savoir qu’elle peut évoluer, fait partie du travail — pas seulement comparer des fonctionnalités techniques.
Comment trancher, concrètement
Section titled “Comment trancher, concrètement”- Besoin d’un serveur relationnel généraliste, gratuit, sans restriction → PostgreSQL ou MariaDB.
- Écosystème déjà tourné vers MySQL (hébergement mutualisé, WordPress, Moodle…) → MySQL ou MariaDB, largement interchangeables pour un usage standard.
- Écosystème Microsoft déjà en place (Active Directory, .NET, Power BI) → SQL Server, malgré son coût.
- Application mobile ou embarquée, pas de serveur à administrer → SQLite.
- Catalogue de données très hétérogène, besoin de mise à l’échelle horizontale simple → MongoDB (en connaissant les implications de la SSPL pour un usage en SaaS).
- Cache, sessions, files d’attente, compteurs à haute fréquence → Redis.
Un point de vue qui mérite sa propre discussion
Section titled “Un point de vue qui mérite sa propre discussion”Un constat revient souvent chez les équipes qui ont adopté PostgreSQL en profondeur : PostgreSQL peut couvrir plusieurs de ces usages à lui seul, y compris certains pour lesquels on choisirait spontanément MongoDB (via son type JSONB) ou même une base vectorielle (via l’extension pgvector). Ce n’est pas un raccourci marketing — c’est un vrai compromis architectural, avec ses avantages et ses limites, qui mérite d’être testé plutôt que supposé. C’est exactement l’objet du module suivant.
Prochaine étape
Section titled “Prochaine étape”Module 3 : PostgreSQL en base multi-modèle — JSONB et pgvector, réellement testés