Nouveau projet backend, il faut stocker des données quelque part. Beaucoup de tutoriels imposent PostgreSQL sans expliquer pourquoi. Une recherche rapide renvoie des comparatifs de performances avec des courbes qui montent, des benchmarks à des millions de requêtes par seconde, et des avis tranchés dans tous les sens. Rien de tout ça n'aide à décider pour un cas précis.
Le choix d'une base de données ressemble à un problème technique pointu. Il l'est beaucoup moins qu'il en a l'air. Sur la plupart des projets qui démarrent, quatre ou cinq bases feraient parfaitement l'affaire, et la différence de performance ne se verra jamais avant plusieurs années de croissance. Ce qui compte au moment de choisir, ce sont des critères plus terre à terre : ton écosystème, le coût des licences, les fonctionnalités dont tu as besoin, et ce que ton équipe sait déjà utiliser.
Cet article te donne une grille de lecture pour trancher sans y passer trois jours. On regarde d'abord pourquoi la question est souvent mal posée, ensuite le principe qui guide un bon choix, puis des scénarios réels, et enfin les pièges qui coûtent cher.
Le problème vient rarement de la base elle-même
Prends un cas courant. Une application de gestion pour une PME, quelques milliers d'utilisateurs, des factures, des clients, des produits. Sur ce type de charge, MySQL, PostgreSQL, SQL Server et Oracle donnent des temps de réponse identiques à l'oeil humain. Les écarts que montrent les benchmarks apparaissent à des volumes que ce projet n'atteindra pas avant longtemps, s'il les atteint un jour.
Beaucoup de débats sur la meilleure base se déroulent sur ce terrain de la performance brute, alors que la performance n'est presque jamais le facteur décisif pour un projet qui commence. Une requête mal écrite ou un index manquant ralentiront ton application mille fois plus qu'un choix de moteur. J'ai vu des applications PostgreSQL ramer parce qu'une table de dix mille lignes n'avait aucun index, pendant que des MySQL bien réglés servaient des millions de lignes sans broncher.
La vraie question à te poser tient en une phrase : dans quel environnement ce projet va-t-il vivre, et avec quelles contraintes ? Un projet PHP hébergé chez un mutualisé bon marché, une API Java en entreprise avec un DSI qui impose Oracle, une stack .NET tournée vers Azure, ou un side-project que tu déploies seul sur un petit serveur. Chacun de ces contextes pousse naturellement vers une base différente, et cette pression compte davantage qu'un tableau comparatif de fonctionnalités.
Le principe : quatre critères qui décident à ta place
Pour choisir vite et bien, passe ton projet au filtre de quatre critères, dans cet ordre. Ils suffisent à éliminer la plupart des candidats et à faire ressortir le bon.
1. L'écosystème et la stack
Le langage et le framework que tu utilises orientent déjà le choix. Un projet .NET s'intègre sans friction avec SQL Server, tous les outils Microsoft parlent la même langue. Une application PHP avec WordPress ou un CMS classique tourne presque toujours sur MySQL ou son fork MariaDB. Un projet Java d'entreprise croise souvent Oracle, parce que c'est ce que la boîte a déjà. Aller à contre-courant de ta stack est possible, mais tu paies ce choix en configuration et en documentation à défricher seul.
2. Le modèle de coût
Là, les écarts sont énormes. MySQL, PostgreSQL et MariaDB sont gratuits et open source, tu les installes sans rien payer. SQL Server propose une édition Express gratuite mais limitée, puis des licences qui grimpent vite. Oracle facture au coeur de processeur, avec des tarifs qui se comptent en dizaines de milliers d'euros et des audits de licences réputés agressifs. Pour un projet perso, une startup ou une PME, ce seul critère écarte souvent Oracle et parfois SQL Server sans autre débat.
3. Les fonctionnalités dont tu as réellement besoin
Certaines bases brillent sur des usages précis. PostgreSQL gère le format JSONB, les données géographiques via l'extension PostGIS, la recherche plein texte et des types de données avancés. Si ton projet manipule des coordonnées de cartes ou des documents semi-structurés, PostgreSQL t'évite des contorsions. MySQL reste plus simple et souvent suffisant pour du CRUD classique. Oracle et SQL Server apportent des outils d'administration poussés utiles aux grosses structures, dont un projet modeste ne verra jamais la couleur.
4. Ce que ton équipe sait déjà faire
Une base que personne ne maîtrise devient un frein permanent. Si les gens autour de toi connaissent MySQL, démarrer sur Oracle pour gagner des fonctionnalités théoriques t'expose à des semaines de galère sur des sujets basiques. La base la mieux adaptée sur le papier n'est pas la meilleure si elle ralentit toute l'équipe au quotidien.
Une fois ces quatre critères posés, le choix se réduit presque toujours à un ou deux candidats évidents. Le reste tient plus de la préférence personnelle que d'un enjeu réel.
Un cinquième critère mérite d'être gardé en tête dès qu'on parle de production : la manière dont tu vas héberger cette base. Beaucoup d'équipes ne gèrent plus leur base à la main et passent par une offre managée chez un hébergeur, où les sauvegardes, les mises à jour et la réplication sont prises en charge. PostgreSQL et MySQL sont proposés en version managée à peu près partout, souvent à petit prix. SQL Server et Oracle le sont aussi, mais leur coût de licence se répercute sur la facture mensuelle. Si tu ne veux pas devenir administrateur de base de données en plus de développeur, ce point pèse dans la balance.
Des scénarios concrets pour se repérer
La théorie se comprend mieux appliquée. Un principe avant les exemples : si le projet a un besoin technique fort, ce besoin décide en premier. Un stockage de données géographiques pousse vers PostgreSQL et son extension PostGIS, quelle que soit ta stack habituelle. Sans contrainte de ce genre, et c'est le cas le plus fréquent, la stack, le budget et l'équipe départagent. Les situations qui suivent sont ces choix par défaut, à ne pas appliquer les yeux fermés.
Un site WordPress ou une boutique en ligne classique
MySQL ou MariaDB. C'est ce que l'écosystème PHP attend, ce que tous les hébergeurs proposent par défaut, et ce que la documentation suppose. Chercher à mettre PostgreSQL derrière WordPress te vaudra des plugins incompatibles pour un gain nul.
Une API moderne, un projet que tu maîtrises de bout en bout
PostgreSQL est un choix par défaut solide, et il devient le choix évident dès que le contenu du projet le demande : stockage de JSON avec le type JSONB, données géographiques via l'extension PostGIS, recherche plein texte poussée. Gratuit, complet, bien documenté, c'est aussi la base la plus citée dans les enquêtes auprès des développeurs professionnels, donc une large communauté et beaucoup de ressources.
Une application interne en environnement Microsoft
SQL Server. Si ta boîte tourne sous .NET, Azure et l'outillage Microsoft, l'intégration est native et l'équipe support connaît déjà le produit. Ici, le coût de licence est absorbé par le contexte de l'entreprise.
Un très gros système d'entreprise, banque ou assurance
C'est le terrain historique d'Oracle, choisi pour ses garanties de support, sa robustesse à très grande échelle et des contraintes réglementaires. Ce choix se décide au niveau du DSI, pas du développeur qui commence un projet.
Un petit projet, un prototype, une application mobile
SQLite mérite une mention. Il fonctionne sans serveur, sous la forme d'un simple fichier posé à côté de ton application. Zéro configuration, parfait pour un prototype, un outil local ou une appli mobile. Beaucoup de projets démarrent dessus avant de migrer vers PostgreSQL le jour où la charge le justifie.
Un mot sur les bases NoSQL comme MongoDB, qu'on oppose souvent aux bases SQL. Elles répondent à des besoins particuliers : gros volumes de données peu structurées, schéma qui change souvent, mise à l'échelle horizontale. Pour une application de gestion avec des relations claires entre les données, une base relationnelle reste plus adaptée et plus sûre. Choisir NoSQL par effet de mode, sur un projet qui aurait été très bien en SQL, complique la vie plus qu'il ne l'améliore.
Si tu débutes sur ce terrain, commencer par une base relationnelle et le langage SQL te donne les fondations qui servent partout. Notre formation SQL et bases de données relationnelles avec MySQL couvre exactement ça : interroger, manipuler et concevoir une base propre, une compétence attendue de tout développeur backend.
Les pièges qui coûtent cher
Quelques erreurs reviennent assez souvent pour mériter un avertissement.
Choisir sur un benchmark
Les benchmarks que tu trouves en ligne mesurent des conditions qui n'ont rien à voir avec ton projet. Ils comparent des configurations extrêmes, sur du matériel spécifique, pour des charges que tu ne verras pas. Décider sur cette base revient à choisir une voiture familiale sur un temps au tour de circuit.
Sous-estimer le coût des licences propriétaires
Oracle facture au coeur de processeur et mène des audits de licences qui surprennent les équipes mal préparées. Une facture inattendue à cinq ou six chiffres a déjà fait basculer plus d'un projet. Avant de partir sur Oracle ou une édition payante de SQL Server, chiffre le coût réel sur trois ans.
Sur-dimensionner pour un besoin qui n'existe pas
Prévoir une base capable d'encaisser des millions d'utilisateurs pour un projet qui en a trois te fait payer, en complexité et parfois en argent, une échelle imaginaire. Tu pourras toujours migrer plus tard si le succès arrive. Ce jour-là, tu auras aussi les moyens et les données pour choisir mieux.
Négliger les droits d'accès
Quelle que soit la base, un compte applicatif qui a tous les droits est une faille qui attend. Un utilisateur de base ne devrait pouvoir faire que ce dont l'application a besoin. Ce sujet dépasse le choix du moteur, il est développé dans notre article sur le principe de moindre privilège.
Dernier point, souvent oublié quand on héberge soi-même : la base doit être isolée et sauvegardée dès le premier jour. Une partie des failles qu'on retrouve dans les projets juniors tient à une base exposée sur internet ou sans sauvegarde. Utiliser Docker pour isoler ta base proprement dans son conteneur est une bonne habitude à prendre tôt.
Que retenir
Commence par regarder le contenu de ton projet : s'il impose du géospatial, du JSON lourd ou de la recherche plein texte, ce besoin tranche et pointe souvent vers PostgreSQL. Sans contrainte de ce type, PostgreSQL et MySQL couvrent la quasi-totalité des besoins gratuitement, et le choix se joue alors sur ta stack, ton budget et l'équipe : SQL Server en contexte Microsoft, Oracle dans les très grosses structures qui l'ont déjà, SQLite pour les prototypes et les petits outils. La performance, elle, arrive tout en bas de la liste.
Et si tu hésites encore après avoir passé ces critères, prends la base que tu connais le mieux. Tu iras plus vite, tu feras moins d'erreurs, et tu pourras toujours changer quand tu auras une raison sérieuse de le faire.
