Pour un SaaS qui va scaler, le bon choix par défaut est PostgreSQL. Il couvre environ 90 % des besoins d’un produit web ou mobile : données transactionnelles, relations entre entités, recherche, JSON, files d’attente légères, et même une partie du vectoriel pour l’IA. La vraie question n’est presque jamais « relationnel ou NoSQL » — c’est « ai-je une raison précise de ne PAS prendre Postgres ». La plupart du temps, non.
PostgreSQL par défaut : pourquoi ça marche 9 fois sur 10
Un SaaS manipule des données structurées et reliées entre elles : des utilisateurs qui appartiennent à des organisations, des abonnements liés à des factures, des projets liés à des tâches. C’est exactement ce pour quoi les bases relationnelles sont faites. Postgres ajoute à ce socle des super-pouvoirs qui évitent d’empiler des briques : colonnes JSONB pour le semi-structuré, recherche plein texte intégrée, extension pgvector pour les embeddings d’IA, contraintes qui garantissent l’intégrité de vos données.
- Transactions ACID : vos paiements et vos données critiques restent cohérents, même en cas de crash.
- Un seul système à opérer, sauvegarder et monitorer au lieu de trois — moins de coûts, moins de pannes.
- Écosystème mûr : Prisma, migrations, réplication, hébergement managé partout (Cloud Run, Neon, Supabase, RDS).
- JSONB quand vous avez besoin de flexibilité, sans renoncer au relationnel pour le reste.
Relationnel vs NoSQL : quand sortir de Postgres
Le NoSQL (MongoDB, DynamoDB, Firestore) n’est pas « plus moderne », il répond à d’autres contraintes. Vous n’y gagnez que si votre cas d’usage colle vraiment : volumétrie massive à écriture très élevée, schéma réellement imprévisible, ou besoin d’une distribution géographique extrême. Pour un SaaS B2B classique en phase de lancement et de croissance, ces contraintes n’existent pas encore — et adopter du NoSQL trop tôt vous fait payer en complexité ce que vous n’utiliserez jamais.
Choisir NoSQL parce que « ça scale » alors qu’on a 200 utilisateurs, c’est optimiser un problème qu’on n’a pas — au prix de ceux qu’on a déjà.
Index, migrations, scaling : les trois réflexes à avoir dès la V1
Une base bien choisie ne suffit pas : ce sont trois habitudes qui décident si votre SaaS tiendra à 10 000 utilisateurs. D’abord les index — une requête qui scanne une table entière est rapide à 100 lignes et catastrophique à 1 million. Indexez les colonnes filtrées et jointes fréquemment, mesurez avec EXPLAIN. Ensuite les migrations : chaque changement de schéma doit être versionné et rejouable (Prisma Migrate), jamais appliqué à la main en production. Enfin le scaling : on monte d’abord verticalement (plus de CPU/RAM), on ajoute des réplicas en lecture, et on ne pense au sharding que très tard — la plupart des SaaS n’y arrivent jamais.
- Index : ciblez les colonnes des clauses WHERE, JOIN et ORDER BY ; un mauvais index coûte à l’écriture, un index manquant tue la lecture.
- Migrations : versionnées, testées, réversibles — la base évolue avec le produit sans downtime.
- Scaling : vertical puis réplicas en lecture ; Postgres tient des millions de lignes sans broncher bien avant qu’on parle de sharding.
Le bon arbitrage pour une V1
Prendre PostgreSQL dès le départ, modéliser proprement, poser les bons index et versionner les migrations : voilà ce qui évite la réécriture à 12 mois. C’est exactement la fondation qu’on met en place dans nos V1 livrées en 7 jours à 15 000 € — Next.js, NestJS, Prisma et Postgres — une base qui vous suit du premier client au passage à l’échelle, sans dette technique cachée.