Un desarrollador redujo los cargos de cómputo de la base de datos serverless de Neon extendiendo el intervalo de sondeo del lado del cliente de 30 segundos a 15 minutos. La pausa más larga permite que la base de datos permanezca inactiva el tiempo suficiente para escalar a cero, eliminando los créditos de cómputo que un sondeo constante cada 30 segundos consumiría de otro modo.

Neon factura por cada segundo que su motor de cómputo está en ejecución. En una configuración serverless típica, cualquier solicitud —por pequeña que sea— mantiene el motor activo. El dashboard de la TV del autor consultaba la base de datos cada medio minuto, a pesar de que los datos mostrados solo cambiaban cuando un usuario sincronizaba manualmente o comenzaba una nueva transmisión. Ese patrón impedía que el pool de cómputo de Neon alcanzara el estado de cero que detiene la facturación, inflando el dashboard de costos de Vercel con picos regulares.

Por qué importaba el sondeo original

  • El dashboard era un componente de React puramente del lado del cliente, por lo que cada instancia del navegador consultaba a Neon directamente.
  • El modelo de precios de Neon vincula el costo al tiempo de cómputo activo, no al número de solicitudes, por lo que una sola consulta cada 30 segundos mantenía un cargo base.
  • El monitoreo de Vercel del autor mostró una correlación entre el tráfico y el uso de cómputo de Neon, confirmando que el sondeo mantenía la base de datos activa.

Soluciones fallidas

Un "debounce" rápido —retrasar la solicitud después de la última interacción del usuario— no ayudó porque el temporizador seguía activándose cada 30 segundos. También intenté usar Vercel Edge Functions, pero eso añadía demasiada complejidad.

La solución sencilla

El único cambio de código necesario fue reemplazar una constante que definía el intervalo de actualización:

  • De 30 segundos → 5 minutos
  • Luego 5 minutos → 15 minutos

Con 15 minutos, Neon tiene tiempo suficiente para reconocer la inactividad y desactivar sus recursos de cómputo. El dashboard sigue siendo funcional: los usuarios siguen viendo los datos más recientes cuando refrescan manualmente, y el sondeo automático ocasional detecta una nueva transmisión sin un ruido constante.

¿Por qué mantener el sondeo en el lado del cliente?

  1. Simplicidad – Sin funciones serverless ni pasos de compilación adicionales.
  2. Expectativas del usuario – El dashboard ya se comporta como una aplicación cliente; un clic manual sigue ofreciendo una actualización instantánea.
  3. Alineación con el modelo de costos – Neon cobra por segundo de cómputo, no por solicitud, por lo que reducir la frecuencia recorta directamente la factura.

Lecciones para desarrolladores serverless

  • Ajusta la frecuencia de sondeo a la cadencia de actualización real de tus datos. Si un conjunto de datos cambia solo unas pocas veces por hora, un intervalo de 15 minutos suele ser suficiente.
  • El sondeo frecuente en un entorno serverless es un generador de costos ocultos; una sola solicitud adicional por minuto puede evitar que una base de datos escale hacia abajo.
  • Pequeños ajustes de configuración pueden producir ahorros significativos sin necesidad de una revisión arquitectónica completa.

En conclusión: el cambio de una sola constante convirtió una base de datos constantemente activa en un componente verdaderamente serverless, reduciendo el gasto de cómputo y preservando la utilidad del dashboard. Para cualquier equipo que utilice Neon o servicios de cómputo similares por segundo, revisar los intervalos de sondeo es una victoria rápida que vale la pena probar hoy mismo.