Choisir sa base de données en 2026 : PostgreSQL, MySQL, SQLite ou service managé ?

La base de données est la décision la plus durable d'un projet : on change un framework front en un trimestre, on migre une base en un an. Bonne nouvelle : pour la grande majorité des projets web, le choix raisonnable est plus simple qu'on ne le dit. Mauvaise nouvelle : les mauvais choix viennent rarement du moteur, et presque toujours d'avoir choisi pour de mauvaises raisons. Reprenons depuis les critères.

Le relationnel d'abord, sauf raison contraire

Les bases relationnelles (PostgreSQL, MySQL/MariaDB, SQLite) restent le défaut sain : schéma explicite, transactions, intégrité référentielle, cinquante ans d'outillage, et un langage — SQL — que chaque génération de développeurs connaît. Les alternatives se justifient par un besoin précis, pas par modernité :

• Document (MongoDB et famille) : des données réellement sans schéma stable. Rare en gestion : un client, une facture, une commande ont un schéma.
• Clé-valeur en mémoire (Redis, Valkey) : cache, sessions, files, compteurs — en complément du relationnel, pas à sa place.
• Recherche (Elasticsearch, Meilisearch, Typesense) : la recherche plein texte avancée — là aussi en complément, quand celle du relationnel ne suffit plus.
• Analytique colonne (ClickHouse, BigQuery) : des agrégations sur des centaines de millions de lignes.

Commencer par le relationnel et ajouter un spécialiste quand un besoin le prouve est un chemin sans regret ; l'inverse — reconstruire de l'intégrité transactionnelle sur une base document — est un classique des refontes douloureuses.

PostgreSQL, MySQL, SQLite : les vraies différences

PostgreSQL est devenu le choix par défaut de l'écosystème : le plus riche fonctionnellement (JSONB pour les données semi-structurées, types avancés, extensions — dont pgvector pour l'IA), une communauté très active, et aucune ambiguïté de gouvernance. C'est notre choix standard chez PYKEngine — biais assumé — précisément parce qu'il couvre sans friction le spectre « données métier + un peu de JSON + un peu de recherche ».

MySQL/MariaDB reste excellent et massivement déployé ; si votre équipe le maîtrise ou que votre écosystème (WordPress, legacy) l'impose, le migrer « pour passer à Postgres » n'a souvent aucun retour sur investissement. Les différences réelles se jouent dans les usages avancés, pas sur un CRUD.

SQLite est le mal-aimé le plus utile : zéro serveur, un fichier, des performances excellentes en lecture. Pour un outil interne, un petit site, une application mono-serveur à trafic modéré, c'est un choix parfaitement sérieux en 2026 — l'écosystème (Litestream pour la réplication, LiteFS) a levé une partie des limites historiques. Sa vraie frontière : les écritures concurrentes massives et les architectures multi-serveurs.

Managé ou auto-hébergé : la question qui coûte le plus

C'est l'arbitrage aux conséquences les plus concrètes :

Notre lecture honnête : le managé se paie cher mais achète de vraies heures d'ingénieur, et pour une équipe sans compétence d'exploitation c'est souvent le bon choix. Nous auto-hébergeons les nôtres (nous racontons pourquoi dans nos coulisses), mais cette voie n'a de sens que si les sauvegardes sont testées en restauration régulièrement — une sauvegarde jamais restaurée n'existe pas.

Les critères qui ne devraient pas décider

• « Ça scale mieux » : à l'échelle d'une PME ou d'une startup avant série B, PostgreSQL ou MySQL sur une machine correcte encaissent des milliers de requêtes par seconde. Le goulot sera vos requêtes et vos index, pas le moteur.
• « Le benchmark dit que… » : les benchmarks mesurent des charges qui ne sont pas la vôtre.
• « On aura peut-être besoin de X un jour » : le jour venu, on ajoute l'outil spécialisé. Payer aujourd'hui la complexité d'un besoin hypothétique est le plus sûr moyen de ne jamais livrer.

Ce qu'il faut retenir

Le choix raisonnable pour la plupart des projets web en 2026 : un moteur relationnel — PostgreSQL si vous partez de zéro, celui que votre équipe maîtrise sinon, SQLite si votre échelle le permet — complété par Redis quand le cache le justifie, et un moteur de recherche le jour où le besoin est réel. La décision importante n'est pas tant le moteur que le mode d'exploitation : managé si personne ne peut opérer une base sérieusement, auto-hébergé si la compétence existe et que les restaurations sont testées. Le reste est du confort.