Neon vs PlanetScale : quelle database serverless pour un fondateur solo ?

La version courte

Deux databases serverless. Deux moteurs différents. Deux paris très différents sur la direction de l'industrie.

Neon donne du Postgres -- la database que la stack web moderne attend -- avec du scaling serverless et un free tier qui permet de construire quelque chose de concret avant de sortir la carte bleue. PlanetScale donne du MySQL propulsé par Vitess avec le meilleur workflow de migration de schéma que quiconque ait livré. Mais il faut $39/mo pour commencer, et la boîte a pivoté vers l'enterprise depuis la suppression du free tier en 2024.

Si on est fondateur solo en train de choisir une database pour son prochain projet, ce choix est plus déséquilibré qu'il n'en a l'air sur le papier.

Le moteur de database : Postgres vs MySQL, ça compte plus qu'on ne le pense

C'est pas une guerre de religion. C'est une question d'écosystème, et elle est très pragmatique.

Postgres est devenu la database par défaut de la stack indie moderne. Quand on installe Prisma ou Drizzle et qu'on suit le quickstart, les exemples utilisent Postgres. Quand on déploie sur Vercel et qu'on active leur produit database, ça tourne sur du Neon/Postgres sous le capot. Quand Supabase, Railway ou Render proposent une database managée, c'est du Postgres. La gravité de l'écosystème tire vers Postgres, et lutter contre cette gravité coûte du temps.

Neon fait tourner du Postgres standard. Ça veut dire colonnes jsonb, types array, full-text search avec tsvector, PostGIS pour les requêtes géographiques, et toute la bibliothèque d'extensions Postgres. L'ORM n'a pas besoin d'un adapter spécial au-delà du driver Postgres standard. Le SQL brut qu'on écrit est le même SQL qu'on écrirait contre n'importe quelle autre instance Postgres. Si on doit quitter Neon un jour, on lance pg_dump et on restore sur n'importe quel hébergeur Postgres de la planète.

PlanetScale fait tourner MySQL via Vitess, la couche de sharding que Google a construite pour scaler YouTube. C'est une techno impressionnante, vraiment. Mais pour un fondateur solo qui build un SaaS, on hérite de l'écosystème MySQL plutôt que celui de Postgres. Ça veut dire pas de jsonb, pas de colonnes array natives, pas d'extensions Postgres, et un pool plus restreint de tutos modernes et de starter templates. On hérite aussi d'une limitation spécifique de Vitess : pas d'enforcement de foreign keys au niveau de la database. L'intégrité référentielle doit vivre dans le code applicatif ou dans l'ORM.

Ce truc des foreign keys, c'est pas théorique. Ça veut dire que la database ne va pas empêcher de supprimer un utilisateur qui a encore des abonnements actifs, ou d'insérer une commande qui référence un produit qui n'existe pas. C'est au code de catcher ces erreurs. La plupart des ORM gèrent ça correctement, mais c'est un truc de plus dont on est responsable.

Pour la plupart des projets démarrés en 2026, Postgres est le chemin de moindre résistance. Pas parce que MySQL est mauvais, mais parce que les outils qu'on utilise déjà ont été pensés pour Postgres.

Le branching : le joyau de PlanetScale

S'il y a une feature où PlanetScale domine vraiment toute l'industrie des databases, c'est le branching.

Le workflow de deploy requests de PlanetScale fonctionne comme une pull request pour le schéma de la database. On crée une branche, on fait ses modifications de schéma sur cette branche, et on ouvre un deploy request. PlanetScale affiche un diff visuel de ce qui va changer. Il vérifie les problèmes de compatibilité. Quand on merge, les modifications sont appliquées via du DDL non-bloquant -- ce qui veut dire que les tables de production restent totalement lisibles et inscriptibles pendant la migration. Pas de downtime. Pas de tables verrouillées. Pas de sueurs froides.

Ça compte à l'échelle. Si on a une table avec dix millions de lignes et qu'on doit ajouter une colonne, un ALTER TABLE naïf peut verrouiller la table pendant des minutes. PlanetScale gère ça de manière transparente grâce aux capacités de DDL en ligne de Vitess. Pour les équipes qui font tourner des databases de production avec du vrai trafic, c'est un avantage opérationnel concret.

Neon a du branching aussi, mais ça résout un problème différent. Les branches Neon sont des snapshots copy-on-write de toute la database -- schéma et données. Elles sont utiles pour créer des environnements isolés de test ou de preview. Mais le branching Neon ne donne pas de diffing de schéma, de deploy requests, ni de DDL non-bloquant. Ce sont des préoccupations séparées qu'on gère avec l'outil de migration de son choix.

L'avis honnête pour les fondateurs solo : le workflow de branching de PlanetScale est meilleur que celui de Neon, point. Mais la plupart des fondateurs solo n'ont besoin ni de l'un ni de l'autre. Si on est le seul à push en prod, et que la plus grosse table a quelques centaines de milliers de lignes, des migrations standard avec Prisma ou Drizzle font parfaitement l'affaire. L'avantage du branching compte quand on a une équipe, un pipeline CI/CD, et des tables assez grosses pour que les schema changes deviennent risqués opérationnellement.

Free tier et pricing : c'est là que la décision devient concrète

Le free tier de Neon donne 0.5 GB de stockage, 191 heures de compute par mois sur une instance partagée, et du database branching basique. C'est assez pour construire un MVP, faire tourner une bêta, et servir ses premiers clients payants. On ne paie rien tant qu'on n'a pas dépassé les limites. Quand c'est le cas, le plan Launch à $19/mo donne 10 GB de stockage et 300 heures de compute. Le plan Scale à $69/mo ajoute l'autoscaling, plus de stockage et des limites supérieures.

PlanetScale n'a pas de free tier. Zéro. Ils ont supprimé le plan Hobby début 2024 et ont dit aux utilisateurs gratuits de passer au payant ou d'exporter leurs données. L'option la moins chère c'est le plan Scaler à $39/mo, qui donne 10 GB de stockage, 1 milliard de row reads, et le workflow de branching. Il y a aussi du pricing Enterprise pour les équipes plus grosses, mais pas de chiffres publics.

Pour un fondateur bootstrappé qui n'a pas encore validé son idée, $39/mo juste pour une database -- avant de payer l'hébergement, l'email, l'auth, ou quoi que ce soit d'autre -- c'est une vraie ligne de dépense. Le burn mensuel grimpe vite quand chaque service facture séparément. Neon à $0/mo ou $19/mo est concrètement moins cher pour le même stade de business.

L'écart de pricing dit quelque chose sur la stratégie de chaque boîte. Neon se bat pour les développeurs et les builders indés. PlanetScale se bat pour les boîtes mid-size et les enterprises. Aucune stratégie n'est mauvaise, mais l'une des deux est clairement plus alignée avec là où on en est quand on lit une page de comparatif comme celle-ci.

Scaling serverless : les deux fonctionnent, différemment

La feature serverless signature de Neon, c'est le scale-to-zero. Quand la database n'a aucune connexion active, le compute s'éteint complètement. On arrête de payer pour le temps d'inactivité. Quand une requête arrive, le compute se relance. Le revers de la médaille, ce sont les cold starts -- sur le free tier, la première requête après une période d'inactivité peut prendre 3-5 secondes. Les plans payants permettent de fixer un compute minimum pour réduire ou supprimer cette latence.

Pour les apps avec du trafic sporadique -- side projects, outils internes, bêtas pré-lancement -- le scale-to-zero est vraiment utile. On ne paie pas pour un serveur qui ne fait rien 22 heures par jour. Pour les apps avec du trafic constant, on gardera un compute minimum de toute façon, et l'angle serverless compte moins.

PlanetScale gère le scaling autrement. Les connexions passent par un proxy Vitess qui distribue la charge sur les shards. Il n'y a pas de vrai scale-to-zero au sens de Neon. La database tourne en permanence, toujours disponible, sans pénalité de cold start. Sous forte charge, Vitess shard la charge horizontalement. C'est la même techno qui scale les databases de YouTube, donc le plafond est extrêmement haut.

Pour un fondateur solo, les capacités de scaling de PlanetScale sont massivement sur-dimensionnées par rapport aux besoins. On ne va pas atteindre le trafic de YouTube avec son premier SaaS. Le modèle serverless de Neon est plus pratique pour les débuts, quand minimiser les coûts pendant les périodes de faible trafic compte plus que gérer des millions de requêtes concurrentes.

Les deux plateformes gèrent le connection pooling, ce qui compte dans les environnements applicatifs serverless où le backend spawn plein de fonctions éphémères qui ont chacune besoin d'une connexion database. Neon inclut un connection pooler intégré. PlanetScale gère ça via la couche proxy Vitess. Aucun des deux ne demande de configurer PgBouncer ou un service de pooling séparé.

Migrations de schéma : outillage standard vs sécurité intégrée

Avec Neon, on apporte sa propre stratégie de migration. C'est la voie Postgres. On utilise Prisma Migrate, Drizzle Kit, des fichiers SQL bruts, ou n'importe quel outil qui parle Postgres. On a la liberté totale, et on a la responsabilité totale. Si on lance un ALTER TABLE qui verrouille une table pendant trente secondes, c'est pour notre pomme. La database ne nous protège pas de nous-mêmes.

Avec PlanetScale, le workflow de deploy requests ajoute une couche de sécurité qui n'existe nulle part ailleurs. Les schema changes passent par un processus de review. Le DDL non-bloquant fait que les tables de prod restent disponibles pendant les migrations. La plateforme empêche activement de shipper un schema change qui causerait du downtime.

Pour les fondateurs solo, l'outillage Postgres standard suffit. On a probablement une seule database de prod avec des tables de taille modeste. Lancer prisma migrate deploy prend une seconde et ne verrouille rien de notable. Le workflow de deploy requests brille quand une mauvaise migration peut coûter de l'argent réel -- quand les tables ont des millions de lignes et que le downtime veut dire du revenu perdu.

Cela dit, le workflow de migration de PlanetScale vaut la peine d'être étudié même si on n'utilise pas le produit. Le modèle mental de traiter les schema changes comme des code reviews, avec des diffs et des approbations, c'est une idée vraiment bonne. Certaines équipes répliquent une version de ça en utilisant Prisma Migrate avec des reviews de PR sur les fichiers de migration.

L'expérience développeur : la gravité de l'écosystème gagne

Neon a le feeling de Postgres parce que c'est Postgres. Chaque tuto qui utilise Postgres fonctionne avec Neon. Chaque ORM qui supporte Postgres fonctionne avec Neon. Chaque outil de monitoring, chaque script de backup, chaque client SQL qui parle Postgres fonctionne avec Neon. La DX n'est pas flashy -- elle est juste normale, dans le meilleur sens du terme.

Neon ajoute un driver serverless (@neondatabase/serverless) qui utilise des connexions HTTP ou WebSocket au lieu du TCP traditionnel. Ça compte pour les déploiements en edge functions sur des plateformes comme Cloudflare Workers ou Vercel Edge Functions où les connexions TCP ne sont pas disponibles. Le driver est bien documenté et fonctionne proprement avec Prisma et Drizzle.

PlanetScale a un dashboard solide et une bonne CLI. Le UI de branching et de deploy requests est bien pensé. Le protocole MySQL veut dire que les clients et outils MySQL standard fonctionnent. Mais dans l'écosystème TypeScript moderne, on tombe constamment sur des petits points de friction. Les starter templates partent de Postgres. Le quickstart Drizzle utilise Postgres. Les exemples communautaires sur GitHub utilisent Postgres. On est toujours à un changement d'adapter et un ajustement de syntaxe du chemin par défaut.

La documentation de PlanetScale est bonne, mais la communauté autour a rétréci depuis la suppression du free tier. Moins de hobbyistes veut dire moins de blog posts, moins de réponses StackOverflow, et moins de projets open source qui l'utilisent comme database par défaut. La DX dépend de l'écosystème autour autant que du produit lui-même.

Le facteur pivot enterprise

Ça compte plus que la plupart des pages de comparatif ne l'admettent.

La décision de PlanetScale de supprimer le free tier et de se concentrer sur l'enterprise n'est pas juste un changement de pricing. C'est un signal sur la direction du produit. Features enterprise, pricing enterprise, support enterprise. La roadmap va de plus en plus servir les besoins de boîtes avec des équipes database dédiées, pas ceux de fondateurs solo qui push en prod depuis un café.

Neon va dans la direction opposée. Ils courtisent activement les développeurs, les builders indés et les startups. Le free tier est généreux. La documentation cible les développeurs individuels. Les intégrations priorisent les outils que les fondateurs indés utilisent vraiment -- Vercel, Next.js, Prisma, Drizzle. Quand une boîte optimise pour notre use case, on a de meilleurs defaults, une meilleure doc et des corrections plus rapides pour les problèmes qu'on rencontre vraiment.

Ça ne veut pas dire que PlanetScale va arrêter de marcher pour les petites équipes. Ça veut dire que les priorités produit et le rythme des améliorations côté développeur vont de plus en plus refléter les besoins enterprise plutôt que les besoins indie. Sur deux ou trois ans, cette divergence se compose.

Quand choisir Neon

• On veut du Postgres et tout l'écosystème qui va avec.
• On a besoin d'un free tier pour valider avant de dépenser.
• On build avec Next.js, SvelteKit, ou un autre framework où Postgres est le défaut.
• On veut du scale-to-zero serverless pour minimiser les coûts en période de faible trafic.
• On tient à la portabilité facile -- pg_dump et on migre vers n'importe quel hébergeur Postgres.
• L'ORM de choix (Prisma, Drizzle, Kysely) fonctionne mieux avec Postgres.
• On déploie sur Vercel et on veut l'intégration la plus étroite (Vercel Postgres tourne sur Neon).

Quand choisir PlanetScale

• On a déjà un codebase MySQL et on ne veut pas migrer vers Postgres.
• On a besoin de schema changes non-bloquants sur des tables larges et à fort trafic.
• L'équipe utilise le workflow de branching et de deploy requests et ça réduit un vrai risque opérationnel.
• On a dépassé la phase de bootstrapping et on peut justifier $39/mo pour un service database seul.
• On valorise les capacités de scaling horizontal de Vitess pour un produit qui a déjà du trafic significatif.
• On construit un produit enterprise où la roadmap de PlanetScale s'aligne avec les besoins.

Verdict

Pour un fondateur solo qui démarre un nouveau projet en 2026, Neon est le choix le plus clair. On a Postgres, que la stack moderne attend. On a un free tier qui permet de build sans carte bleue. On a un pricing simple qui scale avec le business. Et on a un chemin de migration qui fonctionne avec tous les hébergeurs Postgres du marché.

PlanetScale est un produit vraiment excellent qui résout des problèmes difficiles à l'échelle. Le workflow de deploy requests est quelque chose que le reste de l'industrie devrait copier. La fondation Vitess est battle-tested à des échelles que la plupart d'entre nous n'atteindront jamais. Mais l'absence de free tier, le compromis écosystème MySQL et le pivot enterprise en font une recommandation difficile pour des projets bootstrappés.

On prend Neon. On build le truc. Si on atteint un jour l'échelle où l'outillage opérationnel de PlanetScale compte, on aura des clients payants et du revenu pour financer la migration. C'est un bon problème à avoir.