Fin 2024, j'étais à trois semaines dans un projet SaaS pour un client fintech à Canary Wharf. L'app était un tableau de bord Next.js 14 qui tirait des résumés financiers pour les propriétaires de petites entreprises. J'avais opté par défaut pour Vercel Postgres parce que c'était directement dans le dashboard Vercel et je me déplaçais vite. Six semaines plus tard, j'étais en train de câbler manuellement la logique d'authentification au niveau des lignes que Supabase m'aurait donné gratuitement le premier jour. Cela nous a coûté environ deux sprints supplémentaires. Pas idéal.
Je veux être direct à ce sujet : Supabase et Vercel Postgres ne sont pas des outils équivalents en compétition pour le même travail. L'un est une plateforme backend complète. L'autre est une instance Postgres gérée avec un wrapper DX sympathique. Choisir le mauvais ne casse pas votre app, mais cela taxe silencieusement chaque heure que vous y passez.
Voici ce que j'ai vraiment appris en déployant les deux à travers les projets clients chez Seahawk Media.Seahawk Media.
---
Ce qu'ils sont vraiment (pas la version marketing)
Vercel Postgres
Vercel Postgres a été lancé en 2023 et est construit sur Neon, la plateforme serverless Postgres. C'est important et souvent passé sous silence. Vous obtenez essentiellement une base de données Neon avec un SDK saveur Vercel par-dessus et la facturation intégrée à votre plan Vercel.Neon, the serverless Postgres company. That's important and often glossed over. You're basically getting a Neon database with a Vercel-flavoured SDK on top and billing rolled into your Vercel plan.
Ce que vous obtenez : une base de données PostgreSQL, un connection pooling compatible avec edge via @vercel/postgres, et une intégration étroite avec le système de variables d'environnement de Vercel. Vous écrivez du SQL ou utilisez Drizzle/Prisma par-dessus. C'est à peu près tout.@vercel/postgres, and tight integration with Vercel's environment variable system. You write SQL or use Drizzle/Prisma on top of it. That's more or less it.
Supabase
Supabase est une tout autre bête. C'est Postgres en dessous, oui, mais enrobé dans une plateforme qui embarque l'authentification (via GoTrue), les souscriptions en temps réel (via les canaux Phoenix), le stockage de fichiers, les edge functions, et une API REST auto-générée basée sur PostgREST. Les docs d'architecture Supabase valent le coup d'être lues si vous voulez comprendre comment les pièces s'assemblent. Vous choisissez une stack backend avec opinion, pas juste une base de données.Supabase architecture docs are worth reading if you want to understand how the pieces fit. You're choosing an opinionated backend stack, not just a database.
Cette distinction compte immédiatement quand on délimite un projet. Avec Vercel Postgres vous construisez toujours votre authentification, stockage et couches API. Avec Supabase, une part significative de ça est déjà là.
---
Expérience développeur : Jour Un vs Mois Trois
Le jour un avec Vercel Postgres est véritablement rapide. Vous cliquez « Create Database » dans le dashboard, copiez les variables d'env, installez @vercel/postgres, et écrivez votre première requête en environ huit minutes. Je l'ai chronométré une fois. C'est sans friction si vous vivez déjà dans l'écosystème Vercel.@vercel/postgres, and write your first query in about eight minutes. I timed it once. It's frictionless if you already live in the Vercel ecosystem.
Le jour un avec Supabase est aussi rapide, mais il y a plus de surface à comprendre. Le dashboard est dense. Éditeur de table, paramètres d'authentification, politiques RLS, buckets de stockage, edge functions, ça peut faire beaucoup quand vous voulez juste stocker trois tables de données utilisateur.
Voilà le truc, cependant. À partir du troisième mois, la situation s'inverse. Avec Vercel Postgres, je me retrouve constamment à chercher des packages tiers pour combler les lacunes : Clerk ou NextAuth pour l'authentification, Uploadthing ou S3 pour le stockage de fichiers, Pusher pour le temps réel. Chaque intégration ajoute une dépendance, une nouvelle ligne de facturation, et un nouveau point de défaillance. Avec Supabase, ces fonctionnalités sont déjà là et elles communiquent nativement entre elles.
J'ai lancé un projet chez Seahawk l'année dernière, une plateforme communautaire pour une marque de fitness, où nous avons choisi Supabase spécifiquement parce que nous avions besoin de mises à jour en temps réel des classements et d'uploads de contenu généré par les utilisateurs. Nous avons livré ces fonctionnalités en deux semaines. Je suis certain que le même projet sur Vercel Postgres aurait pris quatre semaines, minimum, parce que nous aurions dû assembler Pusher, S3, et Clerk à partir de zéro.
---
Performance et Scalabilité
Les deux exécutent Postgres. La performance brute des requêtes pour les charges typiques des applications web ne sera donc pas votre différenciateur. Les deux supportent le connection pooling. Les deux gèrent sans problème des millions de lignes si vous avez bien indexé.
La vraie histoire de performance, c'est l'architecture.
Vercel Postgres, étant Neon sous le capot, utilise une approche serverless-native où le calcul et le stockage sont séparés. Les cold starts sont une réalité. Aux niveaux gratuit et hobby, si votre base de données n'a pas été touchée depuis un moment, la première requête d'une nouvelle connexion peut prendre 500ms ou plus. Pour une app de dashboard avec un trafic prévisible, c'est une note de bas de page. Pour une app grand public avec des utilisateurs sporadiques, c'est un problème visible.
Supabase fonctionne sur des instances dédiées (ou des connexions poolées via PgBouncer sur les plans payants). Elle ne cold-start pas de la même manière. Le guide Supabase sur le connection pooling explique clairement comment PgBouncer est configuré par plan. Au niveau gratuit, vous obtenez 60 connexions à la base de données. Au niveau Pro, vous en obtenez 200. Si vous dépassez cette limite avec votre app, vous regarderez vers Supavisor (leur pooler plus récent) ou un outil externe comme PgBouncer en mode transaction.Supabase connection pooling guide is clear on how PgBouncer is configured per plan. On the free tier you get 60 database connections. On Pro you get 200. Scale your app past that and you're looking at Supavisor (their newer pooler) or an external tool like PgBouncer in transaction mode.
Aucune des deux plateformes ne va freiner une app SaaS typique sous 10 000 utilisateurs actifs mensuels. Au-delà, la conversation change et vous devriez faire vos propres tests de charge de toute façon.
---
Tarification : Là où ça devient intéressant
C'est là que je vois les gens se faire piéger.
Tarification Vercel Postgres (à partir de 2025-2026) :
- Inclus dans Vercel Pro à $20/mois (avec des limites)
- 256 Mo de stockage sur Pro, puis $0,30/Go au-delà
- Le calcul s'adapte à l'utilisation
Tarification Supabase :
- Tier gratuit : 500 Mo de base de données, 1 Go de stockage de fichiers, 50 000 utilisateurs actifs mensuels pour l'authentification
- Pro : $25/mois, 8 Go de base de données, 100 Go de stockage de fichiers, 100 000 MAU
Si vous payez déjà Vercel Pro, la base de données semble « gratuite » parce qu'elle est incluse. C'est psychologiquement attrayant. Mais dès que vous ajoutez Clerk à $25/mois, Uploadthing et Pusher, votre base de données « gratuite » vous coûte en réalité $80+ par mois en outils associés.
Supabase Pro à 25 $/mois remplace la plupart de ceux-ci. Pour un projet de taille moyenne, Supabase gagne souvent sur le coût mensuel total même si la ligne de la base de données semble plus élevée.
Un bémol honnête : si vous êtes un développeur solo qui déploie des routes API purement serverless sans complexité d'authentification et sans besoin de temps réel, Vercel Postgres est véritablement moins cher et plus simple. Ne payez pas pour des fonctionnalités que vous n'utiliserez pas.
---
Intégration Next.js : les détails pratiques
Les deux bases de données fonctionnent bien avec Next.js App Router et Server Actions. Mais la sensation d'intégration est différente.
Avec Vercel Postgres, le modèle est généralement :
- Écrivez une Server Action ou un Route Handler
- Importez sql depuis @vercel/postgres
sqlfrom@vercel/postgres - Exécutez votre requête
- Retournez les données à votre composant
Simple. Familier. Fonctionne magnifiquement avec Drizzle ORM, j'utilise Drizzle comme mon ORM par défaut depuis environ 18 mois maintenant et ça se marie avec Vercel Postgres sans aucun souci.
Avec Supabase, le pattern typique dans Next.js est :
- Créer un client Supabase (côté serveur via @supabase/ssr)
@supabase/ssr) - Utiliser le client pour faire des requêtes, ou appeler l'API REST auto-générée
- Optionnellement utiliser RLS pour laisser la base de données gérer l'autorisation directement
Le package @supabase/ssr avait quelques imperfections à son lancement en 2023. C'est significativement mieux maintenant. Configurer le flux d'auth par cookie avec Next.js middleware avait l'habitude de nécessiter une implémentation personnalisée ; la documentation actuelle le gère proprement. Néanmoins, c'est plus de setup que Vercel Postgres. Acceptez-le d'entrée.@supabase/ssr package had some rough edges when it first launched in 2023. It's significantly better now. Setting up the auth cookie flow with Next.js middleware used to require a custom implementation; the current docs handle it cleanly. Still, it's more setup than Vercel Postgres. Accept that going in.
Une chose que j'aime vraiment à propos de Supabase dans Next.js : Row Level Security signifie que je peux écrire une requête de base de données dans une Server Action sans me soucier d'exposer accidentellement les données d'un autre utilisateur. La logique d'autorisation vit dans la base de données, pas éparpillée dans mon code applicatif. C'est une vraie victoire architecturale sur n'importe quelle app multi-tenant.
---
Quand choisir Vercel Postgres
- Vous construisez un site de contenu simple, un blog, ou un outil interne sans exigences d'auth (ou vous êtes heureux de gérer l'auth séparément)
- Vous êtes déjà profondément intégré à l'écosystème Vercel et la tarification groupée est avantageuse
- Votre équipe maîtrise bien SQL et souhaite écrire des requêtes brutes ou utiliser Drizzle sans surcharge d'abstraction
- Vous prototypez rapidement et savez que vous réevaluerez votre infrastructure dans 90 jours
---
Quand choisir Supabase
Utilisez ceci comme liste de contrôle. Si vous cochez trois critères ou plus, choisissez Supabase :
- Vous avez besoin d'authentification utilisateur (email/mot de passe, OAuth social, liens magiques)
- Vous construisez des fonctionnalités en temps réel : fils d'actualité, édition collaborative, indicateurs de présence
- Vous voulez un stockage de fichiers sans configuration de politiques S3
- Vous créez un SaaS multi-locataire où l'isolement des données au niveau des lignes est important
- Vous vous attendez à avancer vite et voulez que les préoccupations backend soient déjà résolues
- Votre projet a un stakeholder non-développeur qui utilisera le dashboard pour inspecter les données
J'ai utilisé Supabase sur une plateforme de listing immobilier en 2025. Le client avait besoin que les agents téléchargent des images, que les acheteurs sauvegardent leurs favoris en temps réel, et un panel admin avec des rapports basiques. Auth, stockage, realtime, RLS, tout était couvert. Nous avons utilisé l'éditeur de table intégré de Supabase pour que le client gère directement les annonces. Aucun panel admin personnalisé nécessaire. Ça seul nous a économisé une semaine.
---
La Question de la Dépendance Fournisseur
Ça vaut le coup de le nommer. Les deux options vous attachent à une infrastructure spécifique, mais de manière différente.
Avec Vercel Postgres (Neon), vos données sont dans une base de données Neon. Neon est en fait assez ouvert pour que migrer vers une instance Postgres auto-hébergée soit gérable. pg_dump, pointez vers votre nouvel hôte, c'est fait. La dépendance est vraiment la couche DX de Vercel, pas les données elles-mêmes.pg_dump, point it at your new host, done. The lock-in is really Vercel's DX layer, not the data itself.
Avec Supabase, la dépendance à la base de données est similaire (c'est Postgres, après tout) mais la dépendance à la plateforme est plus significative. Votre auth est GoTrue. Votre stockage est Supabase Storage. Votre realtime est une configuration Phoenix channel. Migrer tout ça vers une pile différente, c'est plus d'une semaine de travail. C'est un vrai compromis à reconnaître. Supabase offre l'auto-hébergement via Docker, consultez le guide d'auto-hébergement de Supabase, ce qui atténue un peu la préoccupation fournisseur.Supabase self-hosting guide, which mitigates the vendor concern somewhat.
Aucun n'est une dépendance catastrophique. Mais si vous construisez quelque chose que vous devrez posséder entièrement dans trois ans, tenez-en compte dans la discussion.
---
FAQ
Supabase est-il simplement Firebase mais avec Postgres ?
Grosso modo oui, mais cette formulation sous-estime l'aspect Postgres. Firebase utilise Firestore, une base de données documentaire avec son propre modèle de requête. Supabase vous donne une base de données entièrement relationnelle avec les jointures, les transactions, les clés étrangères, et tout ce qui rend Postgres utile. La comparaison avec Firebase porte surtout sur la philosophie « batteries incluses ». Si vous connaissez SQL et que vous construisez un modèle de données relationnel, Supabase est un environnement beaucoup plus confortable que Firebase ne l'a jamais été.
Puis-je utiliser Supabase sans utiliser son système d'authentification ?
Oui. Vous pouvez utiliser Supabase purement comme base de données Postgres gérée et intégrer votre propre authentification avec Clerk ou NextAuth. Certaines équipes le font. Honnêtement, je questionnerais cette décision, vous payez pour la plateforme sans utiliser sa fonctionnalité la plus économe en temps, mais c'est un choix architectural valide si vous avez des opinions fortes sur les fournisseurs d'authentification.
Vercel Postgres fonctionne-t-il avec Prisma ?
Oui. Le package @vercel/postgres fonctionne avec Prisma via le connecteur Postgres standard de Prisma. Vous définissez votre DATABASE_URL dans vos variables d'environnement et Prisma ne se soucie pas de ce qu'il y a derrière. J'ai utilisé Prisma avec Vercel Postgres sur deux projets. Drizzle est maintenant ma préférence pour la sécurité des types et l'absence d'un serveur de migration séparé, mais Prisma fonctionne parfaitement bien.@vercel/postgres package works with Prisma via the standard Prisma Postgres connector. You set your DATABASE_URL in your env vars and Prisma doesn't care what's behind it. I've used Prisma with Vercel Postgres on two projects. Drizzle is my preference now for the type safety and lack of a separate migration server, but Prisma works perfectly fine.
Lequel est mieux pour un développeur indie solo avec un budget serré ?
L'offre gratuite de Supabase est véritablement généreuse : 500 MB de stockage, l'authentification incluse, le temps réel inclus. Pour un projet secondaire ou un produit en phase précoce, c'est difficile à battre. L'offre gratuite de Vercel Postgres est plus limitée et la vraie valeur n'apparaît que si vous êtes déjà sur Vercel Pro. Si je commençais un projet personnel demain, j'opterais pour Supabase sans hésiter.
Qu'en est-il de Neon directement, au lieu de Vercel Postgres ?
Bonne question. Puisque Vercel Postgres est Neon sous le capot, tu peux supprimer l'intermédiaire et utiliser Neon directement. Tu obtiens plus de flexibilité de plans, des fonctionnalités de branching (le database branching de Neon pour les environnements de preview est vraiment brillant), et tu n'es pas lié aux offres tarifaires de Vercel. Si tu utilises Vercel Postgres principalement pour la base de données et non pour l'intégration d'écosystème, considère sérieusement l'utilisation de Neon directement via leur intégration Next.js officielle.official Next.js integration.
---
Le résumé honnête : Vercel Postgres est une excellente base de données pour les projets natifs Vercel où tu veux une décision de moins. Supabase est une plateforme backend qui inclut une excellente base de données. Définis d'abord le périmètre de ton projet, puis choisis l'outil qui correspond à ce que tu construis réellement. J'ai gaspillé des sprints en allant dans l'autre direction. Tu ne dois probablement pas commettre la même erreur.