Accueil › Glossaire › Neon

Neon

Neon est une plateforme PostgreSQL serverless open-source qui sépare le compute du stockage, offrant le scale-to-zero (zéro coût quand la base est inactive), le branching instantané (copies de la base en millisecondes, comme des branches Git) et l’autoscaling automatique. Acquis par Databricks en mai 2025.

Neon : PostgreSQL pensé pour le serverless

Le problème que Neon résout est simple : les bases de données PostgreSQL traditionnelles coûtent cher quand elles ne font rien. Une instance RDS sur AWS ou un serveur Cloud SQL sur Google Cloud tourne et facture 24/7, même si votre application n’a aucun trafic la nuit ou le week-end. Neon change la donne avec une architecture qui sépare le compute du stockage.

Concrètement, quand votre base de données est inactive (aucune requête pendant 5 minutes par défaut), Neon arrête le compute et vous ne payez plus rien pour le CPU et la RAM. Quand une requête arrive, le compute redémarre en moins d’une seconde. Vous ne payez que pour les ressources que vous utilisez réellement. Pour les environnements de développement, de test et les applications avec un trafic variable, l’économie est significative par rapport aux bases managées classiques.

L’autre innovation majeure est le branching. Comme avec Git pour le code, vous pouvez créer une branche de votre base de données en millisecondes. La branche est une copie instantanée qui partage le stockage avec le parent (via copy-on-write), donc elle ne coûte presque rien en espace. Vous pouvez tester un changement de schéma, faire tourner des tests d’intégration ou créer un environnement de preview par Pull Request, le tout sans toucher à votre base de production. C’est transformateur pour les workflows CI/CD.

Architecture technique

Séparation compute/storage

Neon stocke les données dans un stockage objet compatible S3, tandis que le compute (CPU/RAM) tourne dans des machines virtuelles légères. Cette séparation permet le scale-to-zero (arrêter le compute sans perdre les données), l’autoscaling (ajuster la puissance de calcul en fonction de la charge) et le branching (créer des copies logiques sans dupliquer les données). L’architecture utilise le Write-Ahead Log (WAL) de PostgreSQL pour le temps réel et la réplication.

Branching instantané

Le branching est la fonctionnalité phare de Neon. Créer une branche ne copie pas les données. Grâce au copy-on-write, la branche pointe vers les mêmes pages de données que le parent. Seules les modifications (le delta) sont stockées séparément. Résultat : créer une branche d’une base de 100 Go prend quelques millisecondes et ne consomme presque pas de stockage supplémentaire (tant que vous ne modifiez pas beaucoup de données dans la branche).

Les cas d’usage du branching incluent un environnement de preview par Pull Request (chaque PR a sa propre base avec les données de production), les tests d’intégration en CI/CD (base éphémère créée au début du pipeline, supprimée à la fin), le test de migrations de schéma (vérifier qu’une migration fonctionne avant de l’appliquer en production), et le masquage de données sensibles pour les environnements de développement.

Scale-to-zero et autoscaling

Après une période d’inactivité configurable (5 minutes par défaut), le compute s’arrête automatiquement. Au prochain appel, il redémarre en moins d’une seconde (cold start). L’autoscaling ajuste la taille du compute entre un minimum et un maximum que vous définissez. Par exemple, vous pouvez configurer une base qui oscille entre 0,25 CU (quand le trafic est faible) et 4 CU (pendant un pic), sans intervention manuelle.

Tarifs

Neon a refondu ses tarifs fin 2025, passant à un modèle usage-based avec des minimums bas :

Au-delà des quotas inclus, la tarification est usage-based : compute à un tarif par CU-heure (variable selon le plan), stockage à 0,35 $/Go-mois (réduit de 1,75 $ après l’acquisition par Databricks), et branches supplémentaires à 1,50 $/branche-mois. Les branches éphémères (créées et supprimées dans le même cycle) ne coûtent presque rien.

L’acquisition par Databricks

En mai 2025, Databricks a acquis Neon, un mouvement stratégique dans la course à l’infrastructure de données IA. Cette acquisition a eu des conséquences positives pour les utilisateurs : les prix du compute ont baissé de 15 à 25 % et le prix du stockage est passé de 1,75 $ à 0,35 $/Go-mois (une réduction de 80 %). La puissance opérationnelle de Databricks permet à Neon d’offrir une infrastructure plus performante à moindre coût. L’acquisition se place dans un contexte plus large où PostgreSQL est devenu un standard pour les workloads IA (stockage de vecteurs via pgvector, bases de données pour agents), ce qui explique aussi l’acquisition de Crunchy Data par Snowflake à la même période.

Cas d’usage

CI/CD et environnements de preview

C’est le cas d’usage transformateur. Chaque Pull Request peut avoir sa propre branche de base de données, créée automatiquement par le pipeline CI et supprimée au merge. Les développeurs testent avec des données réelles (ou masquées) sans jamais toucher à la production. L’intégration avec GitHub Actions et Vercel est native.

Développement et test

Le scale-to-zero rend les environnements de développement et de staging quasi gratuits. Une base de dev qui ne tourne que pendant les heures de bureau (8h/jour, 5j/semaine) coûte environ 25 % du prix d’une base classique toujours allumée. Chaque développeur peut avoir sa propre branche sans coût significatif.

Bases de données pour agents IA

Le branching instantané et le provisionnement rapide font de Neon un choix naturel pour les agents IA qui ont besoin de créer des bases de données éphémères. Un agent peut provisionner une base, y écrire des données, exécuter des requêtes et la supprimer en quelques minutes, avec un coût quasi nul grâce au scale-to-zero et au copy-on-write. Neon supporte aussi pgvector pour les embeddings, ce qui en fait une base combinée relationnelle + vectorielle pour les pipelines RAG.

Neon fournit un support MCP (Model Context Protocol) qui permet aux agents IA de manipuler la base de données en langage naturel : créer des tables, exécuter des requêtes SQL, modifier le schéma et gérer les branches, le tout via des commandes en anglais courant. Ce positionnement « base de données pour agents » est stratégique : avec l’explosion du vibe coding et des agents autonomes, la capacité à provisionner et manipuler des bases de données par programmation devient un avantage compétitif.

Intégrations écosystème

Neon s’intègre nativement avec les outils de l’écosystème frontend/fullstack moderne. L’intégration Vercel est particulièrement soignée : une branche Neon peut être automatiquement créée pour chaque deployment preview de Vercel, ce qui donne à chaque PR sa propre base de données avec les données de production. L’intégration GitHub Actions permet d’automatiser la création et la suppression de branches dans les pipelines CI/CD. Neon est aussi disponible en tant que service natif sur Azure (via Microsoft Learn/Azure Native Integrations), ce qui ouvre le marché enterprise Azure.

Pour les développeurs frontend, la connection string PostgreSQL standard de Neon fonctionne avec n’importe quel ORM (Prisma, Drizzle, TypeORM, Sequelize) et n’importe quel framework (Next.js, Remix, SvelteKit, Django, Rails). Il n’y a pas de SDK propriétaire à apprendre : c’est du PostgreSQL standard avec des superpowers serverless par-dessus.

SaaS multi-tenant

Le modèle de branching permet d’isoler les données de chaque tenant dans sa propre branche (ou projet), avec un scaling indépendant. Chaque tenant paie proportionnellement à son usage grâce au billing granulaire.

Neon vs Supabase vs PlanetScale

Limites

Cold start

Le scale-to-zero implique un cold start quand la base redémarre. Le temps de démarrage est inférieur à une seconde dans la plupart des cas, mais pour les applications temps réel ou avec des exigences de latence strictes, ce délai peut être perceptible. Vous pouvez configurer un compute minimum (par exemple 0,25 CU) pour éviter le scale-to-zero complet, au prix d’un coût fixe minimal. En pratique, la plupart des applications web tolèrent très bien le cold start de Neon, car la première requête après un redémarrage ajoute moins d’une seconde de latence, ce qui est imperceptible dans un flux de navigation classique. Les applications qui nécessitent une latence garantie en millisecondes (trading, jeux temps réel) devraient cependant maintenir un compute minimum toujours actif.

Pas un BaaS

Neon ne fournit que la base de données. Pas d’authentification, pas d’API auto-générée, pas de stockage fichier, pas de temps réel. Si vous cherchez une solution tout-en-un, Supabase ou Firebase sont plus adaptés. Neon est un choix pour les équipes qui veulent assembler leur propre stack ou qui ont déjà un backend.

Limites du free tier

Le plan gratuit est limité à 0,5 Go par projet (5 Go total sur 10 projets). C’est suffisant pour du prototypage mais très vite insuffisant pour une application avec des données réelles. Le plan Launch à 5 $/mois est le minimum viable pour un projet de production.

Chronologie

Verdict

Neon est le meilleur PostgreSQL serverless du marché. Le scale-to-zero, le branching instantané et le pricing usage-based en font un choix imbattable pour les environnements de développement, les pipelines CI/CD, les workloads variables et les agents IA. L’acquisition par Databricks a renforcé la plateforme tout en baissant significativement les prix.

Si vous avez besoin d’un PostgreSQL managé et que vous ne voulez pas payer pour du compute inactif, Neon est le choix évident. Le plan gratuit (100 CU-heures, commercial autorisé) est excellent pour commencer, et le plan Launch à 5 $/mois est le point d’entrée le plus bas du marché pour un PostgreSQL de production.

Neon n’est pas un remplacement de Supabase (qui offre un backend complet). C’est un remplacement de votre instance PostgreSQL managée (RDS, Cloud SQL, Heroku Postgres) avec des superpowers serverless. Si vous assemblez votre propre stack ou si le branching est critique pour vos workflows de développement, Neon est incontournable.