Een ontwikkelaar verlaagde de compute-kosten van de serverless-database van Neon door het client-side polling-interval te verlengen van 30 seconden naar 15 minuten. De langere pauze zorgt ervoor dat de database lang genoeg inactief blijft om naar nul te schalen, waardoor de compute-credits die een constante poll van 30 seconden zou verbruiken, worden geëlimineerd.

Neon brengt kosten in rekening voor elke seconde dat de compute-engine draait. In een typische serverless-opstelling houdt elke aanvraag — hoe klein ook — de engine wakker. Het TV-dashboard van de auteur bevroeg de database elke halve minuut, ook al veranderde de getoonde data alleen wanneer een gebruiker handmatig synchroniseerde of er een nieuwe uitzending begon. Dit patroon voorkwam dat de compute pool van Neon ooit de nulstand bereikte die de facturatie stopt, waardoor het kostenoverzicht van Vercel regelmatig piekte.

Waarom de oorspronkelijke polling belangrijk was

  • Het dashboard was een puur client-side React-component, dus elke browserinstantie maakte direct contact met Neon.
  • De prijsstelling van Neon koppelt de kosten aan actieve compute-tijd, niet aan het aantal aanvragen, waardoor een enkele hit elke 30 seconden een basisbedrag in stand hield.
  • De Vercel-monitoring van de auteur toonde een correlatie tussen het verkeer en het Neon compute-gebruik, wat bevestigde dat de polling de database wakker hield.

Mislukte oplossingen

Een snelle debounce — het vertragen van de aanvraag na de laatste gebruikersinteractie — hielp niet, omdat de timer nog steeds elke 30 seconden afging. Ik heb ook geprobeerd om Vercel Edge Functions te gebruiken, maar dat voegde te veel complexiteit toe.

De eenvoudige oplossing

De enige benodigde code-wijziging was het vervangen van een constante die het verversingsinterval definieerde:

  • Van 30 seconden → 5 minuten
  • Daarna 5 minuten → 15 minuten

Bij 15 minuten heeft Neon voldoende tijd om inactiviteit te herkennen en de compute-resources af te schalen. Het dashboard blijft functioneel: gebruikers zien nog steeds de nieuwste gegevens wanneer ze handmatig verversen, en de incidentele automatische poll vangt een nieuwe uitzending op zonder constante ruis.

Waarom polling aan de client-zijde behouden?

  1. Eenvoud – Geen extra serverless functies of build-stappen.
  2. Gebruikersverwachtingen – Het dashboard gedraagt zich al als een client-app; een handmatige klik geeft nog steeds een directe update.
  3. Aansluiting bij het kostenmodel – Neon brengt kosten in rekening per seconde compute, niet per aanvraag, dus het verlagen van de frequentie verlaagt direct de rekening.

Lessen voor serverless-ontwikkelaars

  • Stem de polling-frequentie af op het werkelijke update-ritme van je gegevens. Als een dataset slechts een paar keer per uur verandert, is een interval van 15 minuten vaak voldoende.
  • Frequent pollen in een serverless-omgeving is een verborgen kostenpost; één extra aanvraag per minuut kan voorkomen dat een database ooit naar beneden schaalt.
  • Kleine configuratie-aanpassingen kunnen enorme besparingen opleveren zonder een volledige architecturale herziening.

De kern: een enkele wijziging in een constante veranderde een constant actieve database in een echt serverless-component, waardoor de compute-kosten werden verlaagd terwijl het nut van het dashboard behouden bleef. Voor elk team dat Neon of vergelijkbare per-seconde compute-services gebruikt, is het herzien van de polling-intervallen een snelle winst die het waard is om vandaag nog te testen.