Ein Entwickler senkte die Compute-Gebühren für die Serverless-Datenbank von Neon, indem er das clientseitige Polling-Intervall von 30 Sekunden auf 15 Minuten verlängerte. Die längere Pause ermöglicht es der Datenbank, lange genug im Leerlauf zu bleiben, um auf Null zu skalieren, wodurch die Compute-Credits eingespart werden, die ein ständiges 30-sekündiges Polling sonst verbraucht hätte.

Neon berechnet jede Sekunde, in der die Compute-Engine läuft. In einem typischen Serverless-Setup hält jede Anfrage – egal wie klein – die Engine wach. Das TV-Dashboard des Autors fragte die Datenbank alle halbe Minute ab, obwohl sich die angezeigten Daten nur änderten, wenn ein Benutzer manuell synchronisierte oder eine neue Übertragung begann. Dieses Muster verhinderte, dass der Compute-Pool von Neon jemals den Nullzustand erreichte, der die Abrechnung stoppt, was das Vercel-Kosten-Dashboard mit regelmäßigen Spitzen belastete.

Warum das ursprüngliche Polling wichtig war

  • Das Dashboard war eine rein clientseitige React-Komponente, sodass jede Browser-Instanz direkt auf Neon zugriff.
  • Die Preisgestaltung von Neon koppelt die Kosten an die aktive Compute-Zeit, nicht an die Anzahl der Anfragen; daher hielt ein einzelner Aufruf alle 30 Sekunden eine Basisgebühr aufrecht.
  • Das Vercel-Monitoring des Autors zeigte eine Korrelation zwischen dem Traffic und der Neon-Compute-Nutzung, was bestätigte, dass das Polling die Datenbank wach hielt.

Fehlgeschlagene Workarounds

Ein schnelles Debouncing – das Verzögern der Anfrage nach der letzten Benutzerinteraktion – half nicht, da der Timer immer noch alle 30 Sekunden ausgelöst wurde. Ich habe auch versucht, Vercel Edge Functions zu verwenden, aber das erhöhte die Komplexität zu stark.

Die einfache Lösung

Die einzige erforderliche Codeänderung bestand darin, eine Konstante zu ersetzen, die das Refresh-Intervall definierte:

  • Von 30 Sekunden → 5 Minuten
  • Dann 5 Minuten → 15 Minuten

Bei 15 Minuten hat Neon ausreichend Zeit, Inaktivität zu erkennen und die Compute-Ressourcen herunterzufahren. Das Dashboard bleibt funktionsfähig: Benutzer sehen weiterhin die neuesten Daten, wenn sie manuell aktualisieren, und das gelegentliche automatische Polling erfasst eine neue Übertragung, ohne ständigen Datenverkehr.

Warum das Polling clientseitig beibehalten?

  1. Einfachheit – Keine zusätzlichen Serverless-Funktionen oder Build-Schritte.
  2. Nutzererwartungen – Das Dashboard verhält sich bereits wie eine Client-App; ein manueller Klick liefert immer noch eine sofortige Aktualisierung.
  3. Abgleich mit dem Kostenmodell – Neon berechnet pro Sekunde Compute-Zeit, nicht pro Anfrage, daher senkt eine Reduzierung der Häufigkeit direkt die Rechnung.

Lektionen für Serverless-Entwickler

  • Passen Sie die Polling-Frequenz an den realen Aktualisierungsrhythmus Ihrer Daten an. Wenn sich ein Datensatz nur wenige Male pro Stunde ändert, reicht ein 15-Minuten-Intervall oft aus.
  • Häufiges Polling in einer Serverless-Umgebung ist ein versteckter Kostentreiber; eine einzige zusätzliche Anfrage pro Minute kann verhindern, dass eine Datenbank jemals herunterskaliert.
  • Kleine Konfigurationsanpassungen können enorme Einsparungen bewirken, ohne dass eine architektonische Überarbeitung erforderlich ist.

Das Fazit: Eine einzige Änderung einer Konstante verwandelte eine ständig aktive Datenbank in eine echte Serverless-Komponente, wodurch die Compute-Ausgaben gesenkt wurden, während die Nützlichkeit des Dashboards erhalten blieb. Für jedes Team, das Neon oder ähnliche pro-Sekunde-Compute-Dienste nutzt, ist die Überprüfung der Polling-Intervalle ein schneller Erfolg, den es heute zu testen lohnt.