Un développeur a réduit les frais de calcul de la base de données serverless de Neon en prolongeant l'intervalle de polling côté client de 30 secondes à 15 minutes. Cette pause plus longue permet à la base de données de rester inactive suffisamment longtemps pour passer en mode « scale to zero », éliminant ainsi les crédits de calcul qu'un polling constant toutes les 30 secondes aurait consommés.
Neon facture chaque seconde où son moteur de calcul est actif. Dans une configuration serverless typique, n'importe quelle requête — aussi infime soit-elle — maintient le moteur en éveil. Le tableau de bord TV de l'auteur interrogeait la base de données toutes les demi-minutes, même si les données affichées ne changeaient que lorsqu'un utilisateur effectuait une synchronisation manuelle ou qu'une nouvelle diffusion commençait. Ce schéma empêchait le pool de calcul de Neon d'atteindre l'état zéro qui arrête la facturation, gonflant ainsi le tableau de bord des coûts de Vercel avec des pics réguliers.
Pourquoi le polling initial était important
- Le tableau de bord était un composant React purement côté client, chaque instance de navigateur interrogeait donc Neon directement.
- La tarification de Neon lie le coût au temps de calcul actif et non au nombre de requêtes ; ainsi, une seule requête toutes les 30 secondes maintenait une charge de base.
- La surveillance Vercel de l'auteur montrait une corrélation entre le trafic et l'utilisation du calcul Neon, confirmant que le polling maintenait la base de données active.
Solutions de contournement infructueuses
Un simple debounce — retarder la requête après la dernière interaction de l'utilisateur — n'a pas aidé car le minuteur s'est déclenché toutes les 30 secondes. J'ai également essayé d'utiliser les Vercel Edge Functions, mais cela ajoutait trop de complexité.
La solution simple
Le seul changement de code nécessaire a été de remplacer une constante qui définissait l'intervalle de rafraîchissement :
- De 30 secondes → 5 minutes
- Puis 5 minutes → 15 minutes
À 15 minutes, Neon dispose de suffisamment de temps pour reconnaître l'inactivité et libérer ses ressources de calcul. Le tableau de bord reste fonctionnel : les utilisateurs voient toujours les dernières données lorsqu'ils rafraîchissent manuellement, et le polling automatique occasionnel détecte une nouvelle diffusion sans bavardage constant.
Pourquoi maintenir le polling côté client ?
- Simplicité – Pas de fonctions serverless ou d'étapes de build supplémentaires.
- Attentes des utilisateurs – Le tableau de bord se comporte déjà comme une application client ; un clic manuel permet toujours une mise à jour instantanée.
- Alignement sur le modèle de coût – Neon facture par seconde de calcul, et non par requête, donc réduire la fréquence réduit directement la facture.
Leçons pour les développeurs serverless
- Adaptez la fréquence de polling à la cadence réelle de mise à jour de vos données. Si un ensemble de données ne change que quelques fois par heure, un intervalle de 15 minutes est souvent suffisant.
- Un polling fréquent dans un environnement serverless est un moteur de coût caché ; une seule requête supplémentaire par minute peut empêcher une base de données de passer en mode veille (scale down).
- De petits ajustements de configuration peuvent produire des économies considérables sans refonte architecturale.
En résumé : le changement d'une seule constante a transformé une base de données constamment active en un composant véritablement serverless, réduisant les dépenses de calcul tout en préservant l'utilité du tableau de bord. Pour toute équipe utilisant Neon ou des services de calcul similaires facturés à la seconde, revoir les intervalles de polling est une victoire rapide qui mérite d'être testée dès aujourd'hui.