Optimiser le coût d'une base Neon Postgres en production

Neon facture séparément le compute (vCPU-heures) et le stockage, avec un modèle serverless qui peut soit réduire drastiquement la facture, soit la faire exploser si l'architecture n'est pas pensée en conséquence. Voici les leviers concrets pour garder le contrôle en production.

Comprendre la structure de facturation avant d'optimiser

Neon facture trois éléments distincts :

• Compute : mesuré en CU-hours (Compute Unit = 1 vCPU + 4 Go RAM). Un projet en scale-to-zero ne consomme rien pendant l'inactivité.
• Storage : le volume de données + l'historique WAL nécessaire au point-in-time recovery (PITR).
• Data transfer : sortant uniquement, généralement marginal sauf en cas d'exports massifs.

L'erreur classique est de dimensionner le compute max sans vérifier l'impact du PITR window. Par défaut, Neon conserve l'historique WAL pendant 7 jours (plan Launch) ou 24h (plan Free). Sur une base avec un fort taux d'écriture (logs applicatifs, événements), cet historique peut représenter 2 à 3 fois la taille des données actives. Réduire la fenêtre de rétention à 1-2 jours si votre stratégie de backup externe le permet peut diviser le coût de stockage par 2.

-- Vérifier la taille réelle des données vs l'historique
SELECT pg_size_pretty(pg_database_size(current_database()));

Croisez ce chiffre avec le dashboard Neon (Storage tab) : si l'écart est important, la rétention WAL est le poste à ajuster en priorité, pas le compute.

Configurer l'autoscaling et le scale-to-zero correctement

Le scale-to-zero est activé par défaut sur les branches non-primaires, mais souvent désactivé manuellement sur la branche de production par peur de la latence de cold start (~500ms à quelques secondes selon la taille du compute).

En pratique, sur une architecture Next.js/Vercel avec trafic irrégulier (SaaS B2B, usage bureautique), le scale-to-zero sur la branche main est rentable dès que le trafic nocturne/weekend représente moins de 30% du temps total. Configuration recommandée :

suspend_timeout = 300  # 5 minutes d'inactivité avant suspension
min_cu = 0.25
max_cu = 2

Le vrai piège n'est pas le scale-to-zero, mais l'autoscaling mal borné. Un max_cu trop élevé combiné à des requêtes non optimisées (full scans, absence d'index) fait grimper le compute automatiquement sans alerte visible avant la facture mensuelle. Fixez un max_cu réaliste basé sur un profiling réel (pg_stat_statements), pas sur une marge de sécurité arbitraire.

Maîtriser le coût des branches Neon

Les branches Neon (copy-on-write) sont l'un des arguments de vente principaux, mais aussi la source de dérive de coût la plus fréquente en équipe. Chaque branche de preview créée automatiquement via l'intégration Vercel consomme du compute indépendamment, et le stockage delta s'accumule si les branches ne sont jamais supprimées.

Actions concrètes :

• Automatiser la suppression des branches de preview via un webhook GitHub/Vercel déclenché à la fermeture de la PR (l'intégration officielle Neon-Vercel le fait, mais vérifiez qu'elle est bien active — c'est un oubli fréquent après migration d'équipe).
• Auditer mensuellement les branches actives via l'API Neon :

curl -X GET "https://console.neon.tech/api/v2/projects/{project_id}/branches" \
  -H "Authorization: Bearer $NEON_API_KEY" | jq '.branches[] | {name, created_at}'

• Ne jamais copier la production complète pour un environnement de dev/staging léger. Utilisez plutôt une branche avec un sous-ensemble de données anonymisées, surtout si votre base primaire dépasse 10 Go.

Optimiser les connexions pour réduire le compute effectif

Sur Vercel, chaque invocation de fonction serverless ouvre potentiellement une nouvelle connexion Postgres. Sans pooling, cela déclenche des cycles activation/désactivation du compute Neon inutilement fréquents, chaque réveil consommant du CU même pour des requêtes triviales.

Le driver @neondatabase/serverless avec connexion HTTP (fetch-based) évite ce problème en supprimant le handshake TCP classique. Pour les cas nécessitant des transactions ou du connection pooling classique, PgBouncer intégré (-pooler suffix dans