Guide de choix de base de données Next.js : PostgreSQL, MySQL, MongoDB et services cloud comparés

Le projet doit être en ligne dans 48 heures. Je fixe la console Vercel sur « Add Database », le curseur oscillant entre Postgres, MySQL et MongoDB. Dix onglets ouverts dans le navigateur — certains vantent le quota gratuit de Supabase, d’autres les performances de PlanetScale, d’autres encore MongoDB comme le choix idéal pour Next.js.

Trop d’options. Chacune semble bonne, chacune a ses limites. Pire encore : un mauvais choix peut coûter plus cher à migrer qu’à réécrire le code.

Si vous vivez la même hésitation, cet article est pour vous. Je vous explique clairement les différences entre PostgreSQL, MySQL et MongoDB, et comment choisir entre Vercel Postgres, Supabase, PlanetScale et MongoDB Atlas.

Pas de blabla.

À la fin, trois questions suffiront pour décider rapidement.

Comprendre les bases — les différences essentielles

PostgreSQL vs MySQL vs MongoDB : plus que relationnel vs non relationnel

On dit souvent : PostgreSQL et MySQL sont relationnels, MongoDB est NoSQL. C’est vrai, mais cette classification n’aide pas vraiment au choix — vous ne savez toujours pas lequel prendre.

Changeons d’angle et parlons de leur « personnalité ».

PostgreSQL, c’est le couteau suisse tout-en-un. Données relationnelles classiques, JSON, recherche full-text, données géospatiales, procédures stockées complexes — presque tout y est. Mais la courbe d’apprentissage est un peu raide : beaucoup de choix, facile de se perdre au début.

Côté performance, PostgreSQL excelle sur les requêtes complexes. Des tests montrent qu’il peut être ~30 % plus rapide que des bases comparables sur des jointures multi-tables. Contrepartie : mal configuré, il consomme plus de ressources que MySQL.

MySQL, le vieux compagnon fiable. Léger, mature, documentation abondante, communauté immense — un problème ? Une recherche et vous avez la réponse. Beaucoup de projets legacy l’utilisent pour sa simplicité.

MySQL a aussi ses limites. Extension verticale uniquement : quand la machine plafonne, vous changez de machine, pas de serveurs comme MongoDB. Pour un trafic modéré, pas de souci ; pour une forte concurrence, ça peut devenir un goulot.

MongoDB est différent. Pas de tables, mais des documents JSON. Flexibilité maximale — ajoutez un champ à un document sans ALTER TABLE. Pour des besoins changeants, c’est salvateur.

J’ai déjà fait un CMS où les champs personnalisés des articles changeaient souvent : « durée de lecture » un jour, « recommandations » le lendemain. En MySQL, chaque changement impliquait ALTER TABLE et compatibilité des données historiques. Avec MongoDB, j’ajoutais le champ directement dans le code.

MongoDB n’est pas une solution universelle. Jointures complexes ? Difficile ou maladroit. Transactions strictes ? Supportées, mais moins naturelles qu’en relationnel.

Choisir une base, ce n’est pas « bon » ou « mauvais », c’est « adapté ou non ».

Quand utiliser laquelle ? Trois critères

Pas de « meilleure » absolue. Voici trois dimensions pratiques.

Critère 1 : complexité des relations de données

Le critère central.

Beaucoup de logique « ceci lie cela » ? E-commerce : utilisateurs → commandes → produits → catégories → tags… Jointures fréquentes ? PostgreSQL ou MySQL. Clés étrangères, cohérence transactionnelle : c’est leur terrain.

À l’inverse, données plutôt plates ou indépendantes ? MongoDB simplifie la vie. Exemple : articles et commentaires de blog. Chaque article est un document JSON ; les commentaires s’imbriquent ou se lient simplement. Là, la flexibilité MongoDB est un atout.

Critère 2 : fréquence des changements de besoins

Le product manager change d’avis tous les trois jours ? MongoDB peut vous sauver.

J’ai vu des projets relationnels parfaitement conçus — champs, index, contraintes — puis : « ajoutons des tags utilisateur », « tags multi-sélection », « tags hiérarchiques »… À chaque fois, migrations et scripts jusqu’à l’épuisement.

Avec MongoDB, ajoutez un champ dans le code, gérez la compatibilité en logique applicative. Contrepartie : plus de validation côté code — la base ne vous protège plus autant.

Si la logique métier est stable (finance, ERP), les contraintes relationnelles sont un avantage : elles bloquent les données invalides en base, moins de soucis dans le code.

Critère 3 : habitudes de l’équipe

Ne sous-estimez pas ce point.

Pas de stack « supérieure » absolue, mais l’écart de maîtrise est réel. Équipe SQL depuis des années et MongoDB imposé ? Coût d’apprentissage parfois supérieur au projet. Idem dans l’autre sens.

Dans une startup JavaScript, l’équipe connaissait mal SQL. Avec PostgreSQL, les requêtes complexes demandaient la doc, l’optimisation d’index était obscure. Passage à MongoDB + Mongoose : productivité doublée — l’API ressemble aux objets JavaScript, pas de changement de mentalité.

Ce n’est pas une excuse pour rester dans sa zone de confort. Si le relationnel est nécessaire, il faut apprendre. Mais si les deux approches conviennent, choisissez celle que l’équipe maîtrise le mieux.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Bataille des services cloud — Vercel Postgres, Supabase, PlanetScale, MongoDB Atlas

Comparaison : au-delà du prix

Base choisie, place aux pièges du cloud.

Vercel Postgres, Supabase, PlanetScale, MongoDB Atlas… Tous séduisants, le diable est dans les détails.

Vercel Postgres : la tentation du déploiement en un clic

Projet déjà sur Vercel ? Vercel Postgres est presque le choix le plus simple. Quelques clics, base configurée, variables d’environnement injectées, latence très basse (souvent < 10 ms en benchmark).

Limites : fonctionnalités relativement simples. Pas d’auth intégrée, pas de stockage, pas de subscriptions temps réel. Pour une PostgreSQL seule, parfait ; pour une « suite complète », il faudra d’autres services.

Tarification : 256 Mo gratuits pour les petits projets. Payant à partir de 20 $/mois — pas bon marché, mais l’intégration Vercel peut valoir le prix.

Supabase : le couteau suisse open source

Supabase est l’un de mes favoris. Ce n’est pas qu’une PostgreSQL : auth, stockage, subscriptions temps réel, et Supabase Studio pour l’admin.

Quota gratuit généreux : 500 Mo base + 1 Go stockage — largement suffisant pour MVP et projets perso. Beaucoup de développeurs indépendants font tourner tout leur produit sur le plan gratuit.

Performance ? Honnêtement, inférieure à PlanetScale. Benchmark : ~5 000 QPS pour Supabase, ~17 000 pour PlanetScale. Pour la plupart des apps moyennes, l’écart se ressent peu. Et c’est du PostgreSQL standard, migration facile.

Attention : trafic soudain, le pool de connexions peut devenir un goulot. Le mode Pooler résout le problème en Serverless — une configuration suffit.

PlanetScale : la bête de performance, à un prix

Les perfs sont réelles : ~17 000 QPS (lecture/écriture mixte), ~35 000 en lecture seule — environ trois fois Supabase. Pour la forte concurrence, la différence est nette.

Fonctionnalité notable : branches de base de données, comme Git. Testez les changements de schéma sur une branche, mergez en production. Très utile en équipe.

Mais plusieurs inconvénients :

Premièrement, pas de clés étrangères. Projet dépendant des FK ? Cohérence à gérer en application.

Deuxièmement, cher. PlanetScale a supprimé le plan gratuit en 2024 ; à partir de 34 $/mois. Lourd pour un budget serré.

Mon conseil : forte concurrence ou besoin de branches en équipe, PlanetScale vaut l’investissement. Sinon, des options plus rentables existent.

MongoDB Atlas : flexibilité au prix d’une courbe d’apprentissage

Service officiel MongoDB. 512 Mo gratuits — le double de Vercel Postgres, proche de Supabase. Déploiement simple, multi-régions.

Si vous avez choisi MongoDB, Atlas est quasi par défaut — officiel, stable, mises à jour régulières.

La courbe NoSQL compte. Habitué au SQL ? L’Aggregation Pipeline demande un temps d’adaptation. Les transactions MongoDB existent, mais moins naturelles ; parfois moins performantes.

Piège caché : frais de bande passante. Facturation au stockage et aux requêtes — app très sollicitée, la bande passante peut dépasser le coût de la base. Un ami a vu 60 % de sa facture en bande passante ; optimisation des requêtes + cache ont réduit le coût.

Tableau comparatif rapide :

Coûts cachés : au-delà de l’abonnement mensuel

Section importante — beaucoup s’y font piéger.

L’abonnement mensuel n’est que la partie visible. Les frais cachés font mal.

Limite de connexions : le cauchemar Serverless

Next.js sur Vercel ou autre plateforme Serverless : chaque requête peut lancer une nouvelle instance. Chaque instance ouvre une connexion — quelques centaines de requêtes simultanées et le pool est saturé.

Les pools classiques peinent en Serverless. Erreurs : « Too many connections », « Connection pool exhausted »… Réveil à 3 h du matin par une alerte, je n’en veux plus.

Heureusement, la plupart des services ont réagi. Supabase : mode Pooler. PlanetScale : pool intégré. Vercel Postgres : optimisation native. MongoDB Atlas : à gérer vous-même — librairie de pool ou alertes de connexions.

Frais de bande passante : le tueur silencieux

Base et application dans des régions différentes ? Chaque requête traverse les régions, la facture grimpe.

MongoDB Atlas est le plus visible : facturation aux requêtes et au transfert. Requêtes fréquentes, gros volumes retournés — la bande passante dépasse souvent la base elle-même.

Solutions :

1. Déployer base et app dans la même région
2. Ne retourner que les champs nécessaires, pas de SELECT *
3. Couche de cache pour réduire les requêtes répétées

Coût de montée en charge : investissement long terme

PlanetScale et Supabase facturent par paliers de stockage et connexions. Gratuit ou bas prix au départ, puis saut de tarif avec la croissance.

Exemple : Supabase gratuit 500 Mo, Pro 25 $/mois pour 8 Go. À 10 Go, supplément à payer. Peu en soi, mais sans anticipation, la facture qui double fait mal.

PlanetScale facture aussi au volume de lignes. 34 $/mois pour 10 milliards de lectures et 50 millions d’écritures ; au-delà, facturation à l’usage. Apps à forte écriture : coût qui monte vite.

Coût de migration : le prix d’un mauvais choix

Le coût le plus ignoré.

Migrer, ce n’est pas copier des données : conversion de schéma, adaptation du code, tests… Petit projet : un ou deux jours. Grand projet : des mois.

Un projet MongoDB « pour aller vite », complexité croissante, requêtes relationnelles pénibles — migration vers PostgreSQL. Nouveau schéma : une semaine. Scripts de migration : deux semaines. Environnements test et prod : presque deux mois au total.

Mon conseil actuel : en cas de doute, solutions mainstream et migrables. ORM (Prisma, Drizzle) pour l’abstraction — changement de base moins douloureux côté code.

Cadre de décision — 3 questions pour trancher

Question 1 : quel type de projet ?

Assez de détails techniques. Question concrète : que choisir ?

Un cadre simple. Trois questions, pas de mémorisation de paramètres.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Première question : quel type de projet ?

Cela détermine ~80 % du choix.

Projet perso / MVP rapide

Budget limité, fonctionnalités complètes ? → Supabase

500 Mo + 1 Go gratuits, auth et temps réel inclus — rêve pour un développeur solo. Beaucoup de SaaS tournent sur Supabase gratuit, milliers d’utilisateurs sans problème.

Plus à l’aise en NoSQL ou schéma très flexible ? → MongoDB Atlas

512 Mo gratuits — CMS, blog, collecte de logs.

Startup / petite équipe

Déjà sur Vercel, efficacité avant tout ? → Vercel Postgres

256 Mo gratuits seulement, mais intégration profonde : variables auto, edge network — du temps gagné. En startup, le temps coûte plus que 20 $/mois.

Auth, stockage, suite complète ? → Supabase

Pas qu’une base : backend complet. Authentication, Storage, Edge Functions prêts — des semaines de dev économisées.

Application entreprise / forte concurrence

Gros volume, exigences de performance ? → PlanetScale

~17 000 QPS, ce n’est pas une blague. Branches de base utiles en grande équipe. 34 $/mois, négligeable avec des revenus stables.

Attention : pas de FK. Logique métier très dépendante des contraintes ? À reconsidérer.

Site de contenu / blog / média

Données flexibles, requêtes simples ? → MongoDB Atlas

Articles, commentaires, tags — le document store est naturel. Recherche full-text plus simple qu’en relationnel.

Commentaires ou notifications temps réel ? → Supabase

Realtime basé sur Change Data Capture PostgreSQL — subscription temps réel sans WebSocket maison.

Question 2 : budget et échelle ?

L’argent, toujours.

Phase zéro budget (100 % gratuit)

Supabase (500 Mo + 1 Go) ou MongoDB Atlas (512 Mo).

Vercel Postgres gratuit : 256 Mo seulement, peu de marge. PlanetScale : pas de gratuit, éliminé.

Conseil : auth ou upload de fichiers probable → Supabase. Stockage pur → MongoDB Atlas plus flexible.

Petit budget ( < 50 $/mois)

Supabase Pro (25 $/mois) ou Vercel Postgres (à partir de 20 $/mois).

Supabase Pro : 8 Go base + 100 Go stockage + 50 000 MAU Auth — excellent rapport qualité-prix. Vercel Postgres un peu plus cher, mais stack entière sur Vercel : temps ops économisé.

MongoDB Atlas à l’usage : quelques dollars/mois en petit volume. Surveillez la bande passante.

Budget moyen (50–200 $/mois)

PlanetScale (à partir de 34 $/mois), Supabase Team (599 $/an, ~50 $/mois).

Critère : performance. QPS modéré → Supabase Team plus rentable, collaboration incluse. Forte concurrence → PlanetScale.

Grande échelle / forte concurrence

À ce stade, le cloud perd en rentabilité. Beaucoup passent à l’auto-hébergé : AWS RDS, Google Cloud SQL, cluster PostgreSQL.

Sans DBA dédié, PlanetScale ou Supabase Enterprise reste raisonnable : externaliser l’ops, se concentrer sur le produit.

Question 3 : tolérance à la dette technique ?

Question souvent oubliée, mais cruciale.

Accepter le risque de migration ultérieure

Commencez gratuit, validez le produit. Migration ou upgrade quand le projet prend.

Beaucoup de produits à succès ont suivi ce chemin : MongoDB Atlas gratuit → milliers d’utilisateurs → requêtes complexes → PostgreSQL → trafic massif → cluster auto-hébergé.

Préparez-vous :

1. ORM (Prisma, Drizzle) comme couche d’abstraction
2. Logique d’accès centralisée, pas dispersée
3. Sauvegardes régulières — une porte de sortie en migration

Vouloir une solution durable, moins de friction

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Solutions matures et mainstream : PostgreSQL + Supabase ou PostgreSQL auto-hébergée.

PostgreSQL : base open source la plus mature, écosystème riche, chemins de migration clairs. Supabase aujourd’hui, AWS RDS ou serveur demain — SQL quasi identique.

MongoDB : écosystème plus fermé. Passer au relationnel = quasi refonte.

Mon expérience personnelle

Choix par défaut pour mes nouveaux projets : Next.js + Prisma + Supabase.

Raisons :

• Quota gratuit suffisant, upgrade quand il y a des revenus
• Prisma : typage et migrations rassurants
• Écosystème PostgreSQL : changement de cloud possible à tout moment
• Auth ou Storage nécessaires : Supabase les inclut

Fort trafic ou équipe ops expérimentée : PlanetScale ou auto-hébergé directement.

Checklist de configuration pratique

Démarrage rapide

Assez de théorie, du concret.

Quelques combinaisons courantes — pas de gros blocs de code, mais les points clés à ne pas oublier.

Option 1 : Vercel Postgres + Prisma

Opérationnel en 5 minutes.

Étapes clés :

1. Projet Vercel → « Storage » → « Create Database » → Postgres
2. Variables injectées dans .env, utilisez process.env.POSTGRES_PRISMA_URL
3. Client Prisma : npx prisma generate
4. Configuration pool Prisma — sinon explosion de connexions en Serverless

Points d’attention :

• Bases dev et prod séparées — ne supprimez pas la prod par erreur
• Migrations Prisma versionnées dans git — sinon chaos en équipe

Option 2 : Supabase + Prisma

Le plus complet, idéal avec Auth.

Étapes clés :

1. Créer un projet Supabase, récupérer la chaîne de connexion
2. Variables DATABASE_URL et DIRECT_URL (cette dernière pour les migrations)
3. Activer le mode Pooler Supabase
4. Auth : @supabase/auth-helpers-nextjs, intégration Next.js fluide

Points d’attention :

• Row Level Security (RLS) bien configurée — sinon faille de sécurité
• Realtime désactivé par défaut — activer dans les paramètres de table

Option 3 : MongoDB Atlas + Mongoose

Pour équipes JavaScript.

Étapes clés :

1. Créer un cluster Atlas, récupérer la chaîne (remplacer <password>)
2. Schémas Mongoose — MongoDB est schemaless, mais contraintes en code utiles
3. serverSelectionTimeoutMS à la connexion — éviter timeout au cold start
4. .lean() sur les requêtes — objets JS purs, meilleures perfs

Points d’attention :

• Ne jamais committer la chaîne avec mot de passe — .env.local + .gitignore
• Index à créer manuellement — sinon requêtes très lentes
• Aggregation : courbe d’apprentissage raide — lire la doc à l’avance

Conseils généraux

Quelle que soit l’option :

1. Variables d’environnement : .env.local (local) et .env.production (prod), ne pas mélanger
2. Pool de connexions : obligatoire en Serverless
3. Gestion d’erreurs : try-catch sur les requêtes — ne pas exposer les erreurs DB à l’utilisateur
4. Sauvegardes : régulières — le cloud aussi tombe en panne
5. Monitoring : connexions, latence des requêtes — à surveiller

Conclusion

Retour à la question du début : quelle base pour un projet Next.js ?

Pas de réponse unique, mais un cadre de décision.

Trois questions :

1. Type de projet : perso ? startup ? entreprise ?
2. Budget : zéro ? petit (< 50 $) ? moyen ou grand ?
3. Dette technique : migration acceptable ? ou solution durable dès le départ ?

Encore hésitant ? Conseil conservateur : Supabase + Prisma + PostgreSQL.

Raisons :

• Quota gratuit pour un projet perso jusqu’aux premiers revenus
• Suite complète (Database + Auth + Storage) — temps de dev économisé
• Écosystème PostgreSQL mature, nombreuses options de migration
• Prisma : typage pour un code plus fiable

Besoins spécifiques — performance extrême (PlanetScale), schéma flexible (MongoDB Atlas), intégration Vercel profonde (Vercel Postgres) — choisissez en conséquence.

Dernier mot : le choix de base n’est pas définitif, c’est un processus. Lancez, validez, optimisez ensuite. Ne laissez pas l’hésitation technique retarder la mise en ligne.

Ouvrez votre projet, posez-vous ces trois questions, décidez en 10 minutes, et codez.

Des questions ? Les commentaires sont ouverts.