Alternatives à Neon : Postgres serverless sans les cold starts

Pourquoi les fondateurs cherchent des alternatives à Neon

Neon a résolu un vrai problème. Le Postgres managé traditionnel (RDS, Cloud SQL, Heroku Postgres) facture des instances always-on, que la base traite des requêtes ou qu'elle dorme à 3h du mat. Neon a introduit le Postgres serverless : le compute scale à zéro quand la base est inactive et redémarre à la demande. Pour un fondateur bootstrapé qui surveille chaque euro, payer uniquement l'usage réel semble idéal.

La réalité est plus nuancée.

Les cold starts sont un vrai problème d'UX. Quand Neon scale le compute à zéro après inactivité, la première connexion après un cold start prend 3 à 5 secondes. Pour une app SaaS où le premier chargement de page tape dans la base, c'est 3 à 5 secondes de délai avant que l'utilisateur voie quoi que ce soit. On peut atténuer ça avec le connection pooling et le driver serverless Neon, mais la latence est toujours là. Pour les apps avec du trafic sporadique — ce qui décrit la plupart des produits early-stage — les cold starts arrivent souvent.

Le database branching, c'est mieux sur le papier que dans la vraie vie d'un dev solo. La feature phare de Neon, c'est le branching instantané — on crée une copie copy-on-write de la base de production pour tester, faire des preview environments ou des migrations. C'est puissant pour les équipes avec des pipelines CI/CD et plusieurs développeurs. Pour un fondateur solo qui push directement sur main depuis son laptop, le branching ajoute de la cérémonie sans bénéfice proportionnel. On finit par payer la taxe de complexité d'une feature conçue pour des équipes plus grandes.

La facture devient sérieuse après le free tier. Le free tier de Neon inclut 0,5 Go de storage et 191 heures de compute sur une instance partagée. Dès qu'on a besoin de plus, le plan Launch démarre à 19 $/mois et le plan Scale à 69 $/mois. Pour un service qui ne fournit que la base de données (pas d'auth, pas de storage, pas de functions), c'est une part significative du burn mensuel. Comparez ça à des plateformes comme Supabase qui embarquent un backend complet pour 25 $/mois.

L'abstraction serverless a des fuites. Neon utilise un connection pooler pour gérer le modèle de compute serverless. Ça fonctionne bien avec leur driver serverless, mais les drivers Postgres standard se comportent parfois différemment. Les connexions longues, les prepared statements et certaines extensions Postgres ne marchent pas exactement comme sur du Postgres traditionnel. On fait tourner du Postgres, mais c'est du Postgres avec des astérisques.

Rien de tout ça ne rend Neon mauvais. Ça en fait un outil spécifique optimisé pour des cas d'usage spécifiques. Les alternatives ci-dessous optimisent pour des priorités différentes.

Comment on a évalué ces alternatives

Chaque alternative a été évaluée sur ce qui compte vraiment pour un dev solo ou une petite équipe qui construit un produit SaaS :

• Fiabilité always-on : La base répond-elle instantanément, ou est-ce que les cold starts impactent l'UX ?
• Prévisibilité du prix : Peut-on estimer sa facture mensuelle à partir de son usage actuel ?
• Compatibilité Postgres : Quelle part de l'écosystème Postgres (extensions, outils, ORM) fonctionne sans modification ?
• Complétude de la plateforme : On obtient juste une base, ou la plateforme inclut auth, storage et autres services ?
• Chemin de migration : Si on dépasse le service ou qu'on doit partir, à quel point les données sont-elles portables ?

On a évalué spécifiquement du point de vue des produits SaaS indie avec 100 à 10 000 utilisateurs — la fourchette où le choix de base de données compte le plus parce qu'on a dépassé le stade du prototype sans être au scale où toutes les options fonctionnent.

Analyse détaillée : ce que chaque alternative fait de mieux

Supabase — le backend complet, pas juste une base

Si on est sur Neon parce qu'on veut du Postgres managé, Supabase donne du Postgres managé plus tout ce qu'on allait construire séparément. Auth avec email, OAuth et magic links. File storage pour les uploads utilisateur. Abonnements real-time pour les données live. Edge functions pour la logique côté serveur. Un SDK, un dashboard, une facture.

L'instance Postgres sur Supabase, c'est du Postgres standard. Les modèles Prisma, les schémas Drizzle et les requêtes SQL brutes fonctionnent sans modification. Les policies Row Level Security permettent de définir le contrôle d'accès au niveau de la base au lieu d'écrire du middleware d'auth dans la couche API. Pour un builder solo, éliminer un service d'auth complet du stack fait économiser à la fois de l'argent et des maux de tête d'intégration.

Le free tier donne 500 Mo de storage base, 1 Go de file storage et 50 000 utilisateurs actifs mensuels pour l'auth. Les projets se mettent en pause après une semaine d'inactivité, ce qui est pénible pour les side projects mais ce n'est pas un cold start — un projet en pause prend environ une minute à se réveiller, et on reçoit un email d'avertissement avant. Le plan Pro à 25 $/mois supprime la mise en pause et donne 8 Go de storage base.

Là où Supabase est en retrait par rapport à Neon, c'est sur les fonctionnalités spécifiques à la base. Pas de branching. Pas de scale-to-zero (l'instance base tourne en continu sur les plans payants). Pas d'autoscaling — on choisit une taille de compute et on upgrade manuellement quand on a besoin de plus. Si on veut spécifiquement le comportement Postgres serverless, Supabase ne le propose pas.

Le moteur real-time fonctionne via la réplication logique Postgres. On s'abonne aux changements sur n'importe quelle table en filtrant par conditions. C'est moins transparent que les listeners real-time Firestore, mais pour les dashboards, les flux de notifications et les features collaboratives, ça fonctionne sans ajouter un service séparé type Pusher ou Ably.

Quand choisir Supabase : On veut Postgres plus auth, storage et functions dans une seule plateforme. On construit une app web où la complexité backend est répartie sur plusieurs problématiques, pas juste la base de données.

PlanetScale — le branching fait comme il faut, en MySQL

PlanetScale est construit sur Vitess, le système de clustering MySQL qui fait tourner YouTube. Si c'est le branching de Neon qui vous a attiré, PlanetScale fait le branching mieux que tout le monde — mais c'est du MySQL, pas du Postgres.

Le workflow de branching est vraiment excellent. On crée une branche, on fait ses changements de schéma, on ouvre un deploy request (comme une pull request pour la base). PlanetScale montre le diff, vérifie les conflits de schéma et permet de merger en sécurité. Les changements de schéma sont non-bloquants — modifier une table avec des millions de lignes ne bloque ni les lectures ni les écritures. C'est le workflow qui rend le database branching réellement utile plutôt qu'une feature qui sonne bien en démo.

Le compromis, c'est MySQL au lieu de Postgres. Si l'application utilise des colonnes jsonb, des arrays Postgres, la recherche full-text avec tsvector, PostGIS pour les requêtes géographiques ou n'importe quelle extension Postgres, PlanetScale n'est pas un remplacement drop-in. L'ORM doit passer sur un adaptateur MySQL. Les requêtes SQL brutes doivent être en syntaxe MySQL.

PlanetScale n'applique pas non plus les foreign keys au niveau base. C'est une limitation de Vitess. L'intégrité référentielle doit être gérée dans le code applicatif ou l'ORM. Pour certains devs, c'est rédhibitoire. Pour ceux qui valident déjà les relations dans la logique applicative, c'est un non-sujet.

La tarification commence à 39 $/mois pour le plan Scaler avec 10 Go de storage et 1 milliard de row reads par mois. Il n'y a plus de free tier — PlanetScale l'a supprimé début 2024. Pour un side project ou un MVP pré-revenu, 39 $/mois juste pour une base de données, c'est cher. Pour un produit avec des clients payants, le workflow de branching et la sécurité opérationnelle justifient probablement le coût.

Quand choisir PlanetScale : On valorise la sécurité des changements de schéma plus que la compatibilité Postgres, et le projet utilise déjà MySQL ou on part de zéro sans dépendance Postgres.

Railway Postgres — juste une base, sans opinions

Railway Postgres, c'est l'option anti-serverless. Pas de scale-to-zero, pas de branching, pas d'autoscaling. On obtient une instance Postgres qui tourne en continu, stocke les données et répond aux requêtes. Cette simplicité est le but.

On provisionne une base en un clic depuis le dashboard Railway. La connection string est automatiquement disponible pour tout service Railway dans le même projet. Si on déploie son app sur Railway, la base et l'application vivent dans le même dashboard avec une facturation et des logs unifiés. Pas de comptes séparés, pas de config réseau cross-platform.

Le plan Hobby coûte 5 $/mois et inclut 5 $ de crédits d'usage. Une instance Postgres avec un petit dataset coûte typiquement 3 à 8 $/mois en compute et storage. Pour un MVP SaaS à faible trafic, les crédits inclus couvrent souvent la base entièrement. Le plan Pro à 20 $/mois offre plus de ressources et supprime les limites hobby.

Comme Railway Postgres est always-on, il y a zéro cold start. La première requête après une heure d'inactivité répond aussi vite que la millième requête en pic de trafic. Pour les applications où la latence API constante compte plus qu'économiser quelques dollars sur le compute inactif, cette prévisibilité est précieuse.

La limitation, c'est que Railway Postgres est lié à la plateforme Railway. On peut s'y connecter depuis des services externes (il expose un endpoint TCP public), mais le dashboard, les backups et les outils de gestion sont tous dans Railway. Si on déplace l'application hors de Railway, on déplace aussi la base.

Les backups automatiques quotidiens sont inclus. Le point-in-time recovery est disponible sur les plans supérieurs. Les extensions comme pgvector, PostGIS et pg_trgm sont supportées. C'est du Postgres standard sur l'infra Railway — rien d'exotique, rien de surprenant.

Quand choisir Railway Postgres : On déploie déjà sur Railway, ou on veut le Postgres managé le plus simple sans complexité serverless. Bon choix pour les fondateurs qui veulent juste une base fiable sans avoir besoin du branching ni des features de scaling.

Turso — du SQLite at the edge, répliqué mondialement

Turso adopte une approche fondamentalement différente. Au lieu du Postgres managé, on obtient des bases libSQL (un fork de SQLite) répliquées vers des points de présence dans le monde entier. Les lectures sont servies depuis la réplique la plus proche. Les écritures passent par une région primaire et se répliquent vers les autres.

Pour les applications à forte lecture — ce qui décrit la plupart des produits SaaS où les utilisateurs lisent les données bien plus souvent qu'ils n'écrivent — cette architecture délivre une latence de lecture sous les 10 ms mondialement. Un utilisateur à Singapour lit depuis une réplique à Singapour. Un utilisateur à Francfort lit depuis une réplique à Francfort. Pas de goulot d'étranglement single-region pour les lectures.

La compatibilité SQLite rend le dev local trivial. La base de test est un fichier sur le laptop. Le même SQL, les mêmes types de données, le même comportement qu'on voit en local tourne en production. Pas de conteneurs Docker, pas d'installation Postgres locale, pas de problèmes de parité d'environnement.

Turso se marie naturellement avec Drizzle ORM pour les projets TypeScript. Drizzle génère des requêtes SQL type-safe avec zéro overhead runtime. La combinaison donne des données répliquées à l'edge avec une type safety complète de la base à l'UI.

Le free tier est généreux : 500 bases, 9 Go de storage total et 25 millions de row reads par mois. Le plan Scaler à 29 $/mois augmente significativement le storage et les lectures. Pour la plupart des projets indie, le free tier couvre le développement et le début de la production.

La limitation principale, c'est que c'est du SQLite, pas du Postgres. Pas de stored procedures. Pas de type jsonb (même si les fonctions JSON existent). Pas d'extensions Postgres. Pas de PostGIS. Si l'application dépend de fonctionnalités spécifiques à Postgres, Turso n'est pas un remplacement. C'est une architecture différente pour les applications où la latence de lecture et la distribution mondiale comptent plus que la compatibilité Postgres.

Aussi, Turso est une base de données, pas une plateforme. Pas d'auth, de storage ni de functions intégrés. On assemble ça soi-même — Clerk ou Lucia pour l'auth, Cloudflare R2 pour le storage, edge functions sur Cloudflare Workers ou Deno Deploy. Ça donne de la flexibilité mais demande plus de décisions architecturales dès le départ.

Quand choisir Turso : L'application est à forte lecture, les utilisateurs sont distribués mondialement et on veut des lectures sous les 10 ms sans gérer un cluster Postgres distribué. Idéal quand on couple avec une plateforme d'edge compute.

CockroachDB Serverless — du Postgres distribué pour les paranos

CockroachDB Serverless, c'est ce qu'on sort quand l'idée d'un seul serveur de base de données qui tombe donne des sueurs froides. C'est une base SQL distribuée qui réplique les données sur plusieurs nœuds et zones, et survit aux pannes matérielles et même aux coupures de régions entières automatiquement.

Le protocole Postgres-compatible signifie que la plupart des drivers, ORM et outils Postgres fonctionnent sans changement. On se connecte avec Prisma, Drizzle ou psql et ça se comporte comme du Postgres — avec quelques bémols. Toutes les extensions Postgres ne sont pas supportées, certains types de données se comportent légèrement différemment, et certains patterns de requêtes performent différemment à cause de la couche de consensus distribué.

Le free tier offre 10 Go de storage et 50 millions de request units par mois. Pour un projet indie, c'est généreux. Les request units sont l'abstraction de tarification de CockroachDB — une lecture simple peut valoir 1 RU, un join complexe peut en valoir 8. Prédire le coût exact demande de comprendre ses patterns de requêtes, ce qui est plus dur que de prédire une facturation basée sur le storage.

Le tier serverless scale à zéro, comme Neon. Les cold starts existent mais sont typiquement de 1 à 2 secondes — plus courts que ceux de Neon. L'architecture distribuée ajoute une latence de base à chaque requête à cause du consensus. Une simple requête point-query qui prend 1 ms sur un Postgres single-region peut prendre 5 à 10 ms sur CockroachDB. Pour la plupart des apps web, c'est imperceptible pour les utilisateurs. Pour les systèmes real-time critiques en latence, ça compte.

La réplication multi-région est la killer feature. Les données survivent à une coupure complète de région sans qu'on configure quoi que ce soit. Pour les projets indie, c'est probablement overkill. Pour un produit SaaS avec des clients payants qui attendent des garanties d'uptime, la tranquillité d'esprit vaut la latence de requête ajoutée.

Quand choisir CockroachDB Serverless : On a besoin de résilience multi-région et on ne peut pas se permettre de downtime. Aussi raisonnable pour le free tier généreux si la latence du consensus distribué ne gêne pas.

Xata — du Postgres avec search et fichiers intégrés

Xata enveloppe Postgres avec de la recherche full-text, du vector search et des fichiers attachés intégrés. Si l'application est riche en contenu — un CMS, une base de connaissances, un outil de gestion documentaire, une marketplace avec des fiches produit — Xata élimine deux ou trois services séparés de l'architecture.

La recherche full-text fonctionne out of the box sans déployer Elasticsearch, Typesense ou Meilisearch à côté de la base. On définit les colonnes searchable et Xata construit et maintient l'index. Le vector search pour les features de similarité IA fonctionne de la même façon. Pour un dev solo, ne pas gérer une infra de recherche séparée réduit significativement la complexité opérationnelle.

Les fichiers attachés vivent à côté des enregistrements en base. On uploade une image sur une ligne, et Xata la stocke, génère des thumbnails et la sert depuis un CDN. Pas de bucket S3 séparé, pas de presigned URLs, pas d'intégration de service de storage. Pour les applications riches en contenu, c'est remarquablement pratique.

L'UI type spreadsheet permet de parcourir et éditer les données visuellement. Les membres non-techniques de l'équipe peuvent consulter le contenu, corriger les données et comprendre la base sans connaître SQL. Si on a un co-fondateur ou un premier collaborateur qui n'est pas développeur, cette accessibilité compte.

Le free tier inclut 15 Go de storage et 75 requêtes par seconde. Le plan Pro à 20 $/mois augmente les limites. C'est raisonnable pour la plupart des projets indie.

Le compromis, c'est l'abstraction. Xata superpose sa propre API sur Postgres, et tous les patterns SQL bruts ne sont pas directement supportés. Si on a besoin de la flexibilité complète de Postgres — extensions custom, stored procedures complexes, stratégies d'indexation avancées — l'abstraction de Xata peut sembler limitante. Pour le cas d'usage spécifique des applications orientées contenu, le search et la gestion de fichiers intégrés l'emportent sur la perte de flexibilité.

Quand choisir Xata : On construit une application riche en contenu qui a besoin de search et de gestion de fichiers, et on ne veut pas intégrer Elasticsearch et S3 séparément.

Comparatif de coûts pour un SaaS indie typique

Voici ce qu'un workload de base de données SaaS indie typique coûte sur chaque plateforme (5 Go de base, trafic read/write modéré, always-on) :

• Neon Launch : 19 $/mois (300 heures de compute, 10 Go storage)
• Supabase Pro : 25 $/mois (8 Go base, inclut auth/storage/functions)
• PlanetScale Scaler : 39 $/mois (10 Go storage, 1B row reads)
• Railway Postgres : 5-12 $/mois (compute et storage à l'usage)
• Turso Scaler : 29 $/mois (24 Go storage, 1B row reads, réplication edge)
• CockroachDB Basic : 0-15 $/mois (le free tier couvre la plupart des workloads indie, à l'usage ensuite)
• Xata Pro : 20 $/mois (100 Go storage, inclut search et fichiers attachés)

Railway est le Postgres managé le moins cher pour de l'usage always-on. Le free tier de CockroachDB est l'option serverless la moins chère. Supabase est le meilleur rapport qualité-prix si on prend en compte l'auth, le storage et les functions qu'on paierait séparément autrement. PlanetScale est le plus cher mais offre les meilleurs outils opérationnels.

Quand rester sur Neon

Neon reste le bon choix dans des situations spécifiques :

• On a besoin du database branching pour le CI/CD. Si le pipeline de déploiement crée des preview environments avec des branches de base isolées, le branching de Neon est la meilleure option Postgres pour ce workflow.
• On optimise pour zéro coût au repos. Si l'application a de longues périodes sans trafic et qu'on veut vraiment ne rien payer pendant ces périodes, le scale-to-zero de Neon est efficace.
• On veut du Postgres serverless pur. Pas d'opinions de plateforme sur l'auth, le storage ou les functions. Juste une base qui scale automatiquement.
• L'équipe a déjà Neon en production. Le coût de changement de la migration d'une base de production est réel. Si Neon fonctionne, l'herbe n'est pas toujours plus verte ailleurs.

La compatibilité Postgres de Neon est excellente — meilleure que celle de CockroachDB. Le branching fait vraiment gagner du temps aux équipes qui l'utilisent. Et le modèle de tarification serverless fonctionne bien pour les applications avec des workloads prévisibles et en bursts.

Conseils pour la migration

Migrer de Neon vers une autre base Postgres-compatible est simple parce que Neon fait tourner du Postgres standard.

1. Exportez avec pg_dump. Utilisez pg_dump --format=custom pour créer un backup portable de la base Neon. Ça capture le schéma, les données, les index, les fonctions et les triggers.
2. Importez avec pg_restore. Chargez le dump dans la nouvelle base. Vérifiez que toutes les extensions utilisées sont disponibles sur la plateforme cible. Les extensions courantes comme pgvector et pg_trgm sont largement supportées, mais les extensions de niche peuvent ne pas l'être.
3. Mettez à jour les connection strings. Remplacez la connection string Neon dans les variables d'environnement. Si on utilisait le driver serverless Neon (@neondatabase/serverless), il faut passer sur un driver Postgres standard comme pg ou postgres.js. Le driver serverless est spécifique à Neon et ne fonctionnera pas ailleurs.
4. Supprimez le code spécifique Neon. Si on utilisait l'API de branching Neon ou le mode HTTP fetch du driver serverless, il faut les remplacer par des patterns Postgres standard. La plupart des ORM (Prisma, Drizzle, Kysely) abstraient ça — on met à jour la config de connexion et l'ORM gère le reste.
5. Testez le connection pooling. Neon route les connexions via son propre pooler. Le nouveau provider peut utiliser PgBouncer ou pas de pooler du tout. Vérifiez que le pattern de connexion de l'app (nombre de connexions concurrentes, durée de vie des connexions) fonctionne avec le nouveau setup.
6. Monitorez pendant une semaine. Après le changement, surveillez les performances des requêtes de près. Les différents providers Postgres ont des configurations par défaut différentes pour work_mem, shared_buffers et les paramètres du query planner. Une requête rapide sur Neon peut avoir besoin d'un tuning d'index sur un autre provider.

Pour migrer vers une plateforme non-Postgres (PlanetScale, Turso), il faut prévoir significativement plus de temps. On ne déplace pas juste les données — on convertit le schéma, on réécrit les requêtes et on change potentiellement l'adaptateur ORM. Comptez 1 à 3 semaines selon la taille et la complexité de la couche données.