Uno sviluppatore ha ridotto i costi di calcolo del database serverless di Neon estendendo l'intervallo di polling lato client da 30 secondi a 15 minuti. La pausa più lunga permette al database di rimanere inattivo abbastanza a lungo da scalare a zero, eliminando i crediti di calcolo che un polling costante ogni 30 secondi consumerebbe altrimenti.

Neon fattura per ogni secondo in cui il suo motore di calcolo è in funzione. In una tipica configurazione serverless, qualsiasi richiesta — per quanto piccola — mantiene il motore attivo. La dashboard TV dell'autore interrogava il database ogni mezzaminuto, anche se i dati visualizzati cambiavano solo quando un utente effettuava una sincronizzazione manuale o iniziava una nuova trasmissione. Questo schema impediva al pool di calcolo di Neon di raggiungere lo stato "zero" che interrompe la fatturazione, gonfiando la dashboard dei costi di Vercel con picchi regolari.

Perché il polling originale era importante

  • La dashboard era un componente React puramente lato client, quindi ogni istanza del browser interpellava direttamente Neon.
  • Il modello di pricing di Neon lega il costo al tempo di calcolo attivo, non al numero di richieste, quindi una singola chiamata ogni 30 secondi manteneva un addebito di base.
  • Il monitoraggio Vercel dell'autore mostrava una correlazione tra il traffico e l'utilizzo del calcolo di Neon, confermando che il polling manteneva il database attivo.

Soluzioni alternative fallite

Un rapido debounce — ritardare la richiesta dopo l'ultima interazione dell'utente — non ha aiutato perché il timer veniva comunque attivato ogni 30 secondi. Ho provato anche a usare le Vercel Edge Functions, ma ciò ha aggiunto troppa complessità.

La soluzione semplice

L'unica modifica al codice necessaria è stata quella di sostituire una costante che definiva l'intervallo di aggiornamento:

  • Da 30 secondi → 5 minuti
  • Poi 5 minuti → 15 minuti

A 15 minuti, Neon ha tempo a sufficienza per riconoscere l'inattività e spegnere le proprie risorse di calcolo. La dashboard rimane funzionale: gli utenti vedono comunque i dati più recenti quando aggiornano manualmente, e l'occasionale polling automatico intercetta una nuova trasmissione senza un traffico costante.

Perché mantenere il polling lato client?

  1. Semplicità – Nessuna funzione serverless o passaggio di build aggiuntivo.
  2. Aspettative dell'utente – La dashboard si comporta già come un'app client; un clic manuale produce comunque un aggiornamento istantaneo.
  3. Allineamento al modello di costo – Neon addebita per secondo di calcolo, non per richiesta, quindi ridurre la frequenza taglia direttamente la bolletta.

Lezioni per gli sviluppatori serverless

  • Adatta la frequenza di polling alla cadenza di aggiornamento reale dei tuoi dati. Se un set di dati cambia solo poche volte l'ora, un intervallo di 15 minuti è spesso sufficiente.
  • Il polling frequente in un ambiente serverless è un driver di costi nascosto; una singola richiesta extra al minuto può impedire a un database di scalare verso il basso.
  • Piccoli accorgimenti nella configurazione possono produrre risparmi enormi senza una revisione architettonica.

In sintesi: la modifica di una singola costante ha trasformato un database costantemente attivo in un componente veramente serverless, riducendo la spesa di calcolo e preservando l'utilità della dashboard. Per qualsiasi team che utilizzi Neon o servizi di calcolo simili basati sul secondo, rivedere gli intervalli di polling è una vittoria rapida che vale la pena testare oggi stesso.