A developer cut Neon’s serverless-database compute charges by extending the client-side polling interval from 30 seconds to 15 minutes. The longer pause lets the database sit idle long enough to scale to zero, eliminating the compute credits a constant 30-second poll would otherwise consume.

Neon bills for every second its compute engine runs. In a typical serverless setup, any request—no matter how tiny—keeps the engine awake. The author’s TV dashboard queried the database every half-minute, even though the displayed data changed only when a user manually synced or a new broadcast began. That pattern prevented Neon’s compute pool from ever reaching the zero-state that stops billing, inflating the Vercel cost dashboard with regular spikes.

Why the original polling mattered

  • The dashboard was a purely client-side React component, so each browser instance hit Neon directly.
  • Neon’s pricing ties cost to active compute time, not request count, so a single hit every 30 seconds sustained a baseline charge.
  • The author’s Vercel monitoring showed a correlation between traffic and Neon compute usage, confirming that the polling kept the database awake.

Failed workarounds

A quick debounce—delaying the request after the last user interaction—did not help because the timer still fired every 30 seconds. I also tried using Vercel Edge Functions, but that added too much complexity.

The simple fix

The only code change required was to replace a constant that defined the refresh interval:

  • From 30 seconds → 5 minutes
  • Then 5 minutes → 15 minutes

At 15 minutes, Neon has ample time to recognize inactivity and spin down its compute resources. The dashboard stays functional: users still see the latest data when they manually refresh, and the occasional automatic poll catches a new broadcast without constant chatter.

Why keep polling client-side?

  1. Simplicity – No extra serverless functions or build steps.
  2. User expectations – The dashboard already behaves like a client app; a manual click still yields an instant update.
  3. Cost model alignment – Neon charges per second of compute, not per request, so reducing the frequency directly cuts the bill.

Lessons for serverless developers

  • Match polling frequency to the real-world update cadence of your data. If a dataset changes only a few times an hour, a 15-minute interval is often enough.
  • Frequent polling in a serverless environment is a hidden cost driver; a single extra request per minute can keep a database from ever scaling down.
  • Small configuration tweaks can produce outsized savings without an architectural overhaul.

The bottom line: a single constant change turned a constantly-awake database into a truly serverless component, trimming compute spend while preserving the dashboard’s usefulness. For any team running Neon or similar per-second compute services, revisiting poll intervals is a quick win worth testing today.