Cold start serverless Postgres : ce qu'il faut comprendre avant de choisir

Un cold start survient quand le compute qui exécute votre base de données a été mis en veille par inactivité, et qu'une nouvelle requête doit d'abord le redémarrer avant de s'exécuter. Ce n'est pas la latence réseau habituelle d'une connexion TCP/TLS classique : c'est le temps de faire tourner un nouveau processus Postgres et de restaurer son état, avant même que la première requête ne commence à s'exécuter.

Le terme vient du calcul serverless au sens large, où un environnement d'exécution mis à zéro doit redémarrer avant de traiter une requête, qu'il s'agisse d'une fonction serveur ou d'un runtime WebAssembly en périphérie. Nous détaillons ce mécanisme côté fonctions edge dans notre article sur le cold start WebAssembly face aux conteneurs. Pour une base de données, la mécanique diffère : ce n'est pas un binaire compilé qui démarre, mais un serveur Postgres complet qui doit rouvrir ses fichiers, valider son état, puis accepter de nouvelles connexions.

Neon sépare l'architecture de sa base de données en deux couches distinctes : un stockage persistant qui garde les données, et un compute, le processus Postgres lui-même, qui peut être arrêté et redémarré indépendamment. Cette séparation permet à Neon de suspendre le compute d'un projet inactif sans toucher aux données, puis de le relancer à la demande, selon sa documentation officielle.

Sur le plan gratuit, Neon documente un délai d'inactivité par défaut de 5 minutes avant mise en veille du compute. Les plans payants permettent de configurer ce seuil, voire de l'allonger fortement pour un usage à trafic constant. Ce type de valeur par défaut évolue avec les mises à jour produit : vérifiez la documentation Neon à jour au moment de votre lecture plutôt que ce chiffre isolé.

Cette conception sert un usage précis, les environnements éphémères. Une base par branche Git, un environnement de prévisualisation par pull request, une base de test qui ne sert que quelques minutes par jour : faire tourner un compute en continu pour ces usages coûte cher sans bénéfice réel. Suspendre le compute entre deux usages réduit la facture sans supprimer les données, c'est l'argument central du modèle serverless de Neon.

Neon indique dans sa documentation un redémarrage de compute généralement de l'ordre de quelques centaines de millisecondes à quelques secondes, selon la taille du projet et le volume de journal de transactions à rejouer avant que le compute soit prêt. C'est un chiffre publié par l'éditeur lui-même, pas un audit indépendant : traitez-le comme un ordre de grandeur documenté, pas comme une garantie contractuelle.

Pour une mesure en conditions réelles, un outil communautaire public, neon-latency-benchmarks.vercel.app, interroge des projets Neon suspendus à intervalles réguliers et affiche la latence de réveil observée. C'est le type de méthodologie qui compte davantage qu'un chiffre nu de documentation : les conditions de test restent visibles, pas cachées derrière une moyenne marketing. Nous appliquons le même principe dans notre propre méthodologie de benchmark backend : publier le protocole avant de publier un chiffre.

Vercel a construit son offre de base de données Postgres en s'appuyant sur l'infrastructure Neon, un partenariat rendu public en 2024. Au moment de la rédaction, cette intégration Postgres est proposée dans le Vercel Marketplace comme option de stockage aux côtés d'autres fournisseurs. Vérifiez la page produit Vercel à jour : ce type de partenariat évolue vite dans un marché qui change chaque trimestre.

Concrètement, le comportement de mise en veille et de réveil d'une base Postgres provisionnée via Vercel suit la même mécanique que celle décrite ci-dessus pour Neon directement. Ce n'est pas un moteur distinct avec son propre modèle de cold start, c'est la même infrastructure exposée derrière une intégration Vercel.

Non, pas de la même façon. Supabase provisionne une instance Postgres dédiée par projet plutôt qu'un compute serverless suspendu par connexion. Il n'y a donc pas de délai de réveil ajouté à chaque nouvelle session après quelques minutes d'inactivité, contrairement au modèle Neon.

Un mécanisme différent existe cependant sur le plan gratuit : Supabase documente une mise en pause automatique des projets inactifs après une période prolongée, de l'ordre d'une semaine selon sa documentation, avec restauration manuelle depuis le tableau de bord plutôt qu'un réveil automatique à la première requête. C'est un seuil mesuré en jours, pas en minutes, et une action explicite plutôt qu'une reprise transparente : deux différences structurelles avec le cold start Neon, pas une simple variante du même mécanisme. Pour une comparaison complète de l'architecture, notre comparatif détaillé Aurabase vs Supabase documente les autres écarts.

Aurabase ne propose pas de modèle serverless à la Neon. Vérifié dans le code du provisionneur (aura-provisioner, open source sur github.com/aurabase/aurabase) : chaque projet reçoit soit un cluster Postgres dédié géré par CloudNativePG, l'opérateur Kubernetes CNPG, soit une base dédiée sur un cluster CNPG mutualisé entre plusieurs projets d'une même organisation, selon le plan choisi. Dans les deux cas, ce n'est pas un compute unique qui se suspend et se réveille à chaque connexion : c'est un cluster Postgres complet, avec primaire et éventuels réplicas.

Un mécanisme d'hibernation existe bien côté Aurabase, mais il sert un objectif différent. Sur inactivité prolongée, 7 jours par défaut et configurable via une variable d'environnement, seuil vérifié dans le code, le provisionneur met en veille les instances inactives pour libérer des ressources, pas pour optimiser la latence d'un usage intermittent. Réveiller un cluster CNPG en veille recrée ses pods depuis les volumes persistants, un mécanisme structurellement plus lourd qu'un simple redémarrage de processus serverless.

Cette architecture dédiée a une contrepartie directe sur l'isolation et la prévisibilité de performance : un projet ne partage pas son compute avec un autre projet, contrairement à un cluster mutualisé mal dimensionné. Nous détaillons cet arbitrage dans un article dédié : base dédiée vs mutualisée, impact réel sur la performance et l'isolation.

Le modèle serverless à la Neon sert un cas d'usage précis : de nombreux environnements éphémères ou à trafic très intermittent, où payer pour un compute qui tourne en continu n'a pas de sens économique. Une base par branche Git, un environnement de prévisualisation par pull request, un prototype testé quelques fois par semaine : le cold start occasionnel devient un compromis acceptable contre une facture proportionnelle à l'usage réel.

À l'inverse, une architecture Postgres dédiée et toujours active devient préférable dès que la latence de première connexion doit rester prévisible : une API de production à trafic régulier, un backend qui ne peut pas se permettre un pic de latence occasionnel sur la requête d'un utilisateur, ou un système où la p99 compte davantage que le coût d'une branche de test isolée.

Réveil Neon : ordre de grandeur documenté par l'éditeur, non audité indépendamment. Seuil d'hibernation Aurabase : vérifié dans aura-provisioner, variable HIBERNATE_INACTIVITY_DAYS, défaut 7 jours.

Le cold start serverless Postgres n'est pas un concept universel : c'est une conséquence directe de l'architecture Neon, qui sépare stockage et calcul pour suspendre ce dernier entre deux usages. Vercel Postgres en hérite directement via son partenariat avec Neon. Supabase et Aurabase, qui provisionnent des instances Postgres dédiées, exposent un mécanisme différent, mesuré en jours plutôt qu'en minutes, pas conçu pour la même finalité.

Avant de choisir un fournisseur sur ce seul critère, vérifiez trois choses : le seuil d'inactivité réel documenté par le fournisseur, s'il est configurable sur votre plan, et si votre trafic applicatif justifie un compute qui se suspend. Pour un usage à trafic intermittent réel, branches de test ou previews, le modèle serverless a un intérêt économique net. Pour une production à trafic régulier, une architecture dédiée élimine simplement la question.