Sin embargo, este no es un concepto universal. Supabase y Aurabase, que proporcionan instancias dedicadas de Postgres, no exponen este mismo mecanismo de la misma manera. Este artículo detalla lo que Neon realmente documenta en su propio arranque en frío, cómo se comparan Vercel Postgres y Supabase y dónde encaja el modelo de Aurabase, verificado directamente en el código del proveedor en lugar de inferirlo de una página de marketing.
Lo esencial
- El arranque en frío sin servidor se refiere al retraso agregado cuando una base de datos suspendida debe reactivar su proceso antes de responder a la primera solicitud.
- Neon separa el almacenamiento y el cálculo: la computadora entra en suspensión después de un período documentado de inactividad (5 minutos de forma predeterminada en el plan gratuito, configurable en los planes pagos).
- Neon documenta un reinicio normalmente en el orden de unos pocos cientos de milisegundos a unos pocos segundos, una cifra publicada por el editor, medible en vivo a través de la herramienta comunitaria neon-latency-benchmarks.vercel.app.
- Vercel Postgres se basa en la infraestructura Neon: el comportamiento de activación sigue la misma mecánica, bajo una marca diferente.
- Supabase proporciona una base de datos dedicada por proyecto, sin arranque en frío por conexión. Sólo el plan gratuito pausa los proyectos inactivos, con restauración manual.
- Aurabase aprovisiona una base de datos Postgres dedicada por proyecto, un clúster CNPG dedicado o una base dedicada en un clúster compartido: este no es un modelo sin servidor Neon, verificado en el código del aprovisionador.
¿Qué es un arranque en frío para una base de datos Postgres sin servidor?
Un inicio en frío ocurre cuando el proceso que ejecuta su base de datos se pone en suspensión por inactividad y una nueva consulta primero debe reiniciarla antes de ejecutarse. Esta no es la latencia de red habitual de una conexión TCP/TLS típica: este es el momento de iniciar un nuevo proceso de Postgres y restaurar su estado, incluso antes de que comience a ejecutarse la primera solicitud.
El término proviene de la informática sin servidor en general, donde un entorno de ejecución puesto a cero debe reiniciarse antes de procesar una solicitud, ya sea una función de servidor o un tiempo de ejecución de WebAssembly en el borde. Detallamos este mecanismo en el lado de las funciones perimetrales en nuestro artículo sobre inicio en frío de WebAssembly frente a contenedores. Para una base de datos, la mecánica es diferente: lo que se inicia no es un binario compilado, sino un servidor Postgres completo que debe reabrir sus archivos, validar su estado y luego aceptar nuevas conexiones.
1. Inicio de sesión del cliente
Llega una solicitud a un proyecto cuyo proceso está suspendido.
2. Detección del sueño
La plataforma nota que el cálculo ya no está activo.
3. Reiniciar el cálculo
El proceso de Postgres se reinicia y se restaura el estado necesario.
4. Solicitud procesada
La conexión es exitosa, la solicitud se ejecuta normalmente.
Ilustración del mecanismo de arranque en frío, secuencia simplificada, sin valor de tiempo medido.
Por qué Neon pone su computadora en suspensión y a qué velocidad
Neon separa su arquitectura de base de datos en dos capas distintas: almacenamiento persistente que guarda los datos y computación, el proceso de Postgres en sí, que se puede detener y reiniciar de forma independiente. Esta separación permite a Neon suspender el cálculo de un proyecto inactivo sin tocar los datos y luego reiniciarlo cuando lo solicite, según su documentación oficial.
En el plan gratuito, Neon documenta un tiempo de inactividad predeterminado de 5 minutos antes de poner la computadora en suspensión. Los planes pagos le permiten configurar este umbral, o incluso aumentarlo significativamente para usarlo con tráfico constante. Este tipo de configuración predeterminada cambia con las actualizaciones del producto: consulte la documentación de Neon actualizada en el momento de la lectura en lugar de esta cifra aislada.
Este diseño responde a un propósito específico, ambientes efímeros. Una base de datos por rama de Git, un entorno de vista previa mediante solicitud de extracción, una base de datos de prueba que solo se usa durante unos minutos al día: ejecutar una computadora continuamente para estos usos es costoso y no tiene ningún beneficio real. Suspender el cómputo entre dos usos reduce la factura sin eliminar los datos, este es el argumento central del modelo sin servidor de Neon.
¿Cuánto dura un despertador de neón y cómo comprobarlo usted mismo?
Neon indica en su documentación un reinicio del cómputo generalmente del orden de unos cientos de milisegundos a unos pocos segundos, según el tamaño del proyecto y el volumen de registros de transacciones que se reproducirán antes de que el cómputo esté listo. Esta es una cifra publicada por el propio editor, no una auditoría independiente: trátela como un orden de magnitud documentado, no como una garantía contractual.
Para realizar mediciones en el mundo real, una herramienta comunitaria pública, neon-latency-benchmarks.vercel.app, realiza encuestas que suspenden los proyectos de Neon a intervalos regulares y muestra la latencia de activación observada. Este es el tipo de metodología que importa más que una simple cifra de documentación: las condiciones de prueba permanecen visibles, no ocultas detrás de un promedio de marketing. Aplicamos el mismo principio en nuestra propia metodología de referencia de backend : publicar el protocolo antes de publicar una figura.
| Tamaño del proyecto | Más relaciones y volumen de WAL para validar hacen que el reinicio sea más largo. |
|---|---|
| Distancia de región y red | Aumenta la latencia de la conexión, independientemente del propio arranque en frío. |
| plan de precios | Los planes pagos le permiten configurar o ampliar el umbral de inactividad. |
| Frecuencia de conexiones | Un proceso que sigue siendo solicitado regularmente nunca experimenta este retraso. |
Vercel Postgres y Neon: ¿el mismo motor bajo otra marca?
Vercel ha creado su oferta de base de datos Postgres basada en la infraestructura Neon, una asociación que se hizo pública en 2024. Al momento de escribir este artículo, esta integración de Postgres se ofrece en Vercel Marketplace como una opción de almacenamiento junto con otros proveedores. Consulte la página actualizada del producto Vercel: este tipo de asociación evoluciona rápidamente en un mercado que cambia cada trimestre.
Concretamente, el comportamiento de suspensión y activación de una base de datos Postgres suministrada a través de Vercel sigue la misma mecánica que la descrita anteriormente para Neon directamente. No es un motor separado con su propio modelo de arranque en frío, es la misma infraestructura expuesta detrás de una integración de Vercel.
¿Supabase tiene un arranque en frío comparable?
No, no de la misma manera. Supabase proporciona una instancia de Postgres dedicada por proyecto en lugar de un proceso sin servidor suspendido por conexión. Por lo tanto, no se añade ningún retraso en el despertar a cada nueva sesión después de unos minutos de inactividad, a diferencia del modelo Neon.
Sin embargo, existe un mecanismo diferente en el plan gratuito: Supabase documenta una pausa automática de proyectos inactivos después de un período prolongado, del orden de una semana según su documentación, con restauración manual desde el tablero en lugar de un despertar automático en la primera solicitud. Es un umbral medido en días, no en minutos, y una acción explícita más que una recuperación transparente: dos diferencias estructurales con el arranque en frío del Neon, no una simple variación del mismo mecanismo. Para una comparación completa de la arquitectura, nuestra comparación detallada Aurabase vs Supabase documenta otras discrepancias.
Y el modelo Aurabase: por qué la comparación no se aplica tal cual
Aurabase no ofrece un modelo sin servidor como Neon. Verificado en el código del aprovisionador (aura-provisioner, código abierto en github.com/daylami555/aurabase): cada proyecto recibe un clúster de Postgres dedicado administrado por CloudNativePG, el operador CNPG de Kubernetes, o una base dedicada en un clúster CNPG compartido entre varios proyectos de la misma organización, según el plan elegido. En ambos casos, no es un único proceso el que se suspende y se activa en cada conexión: es un clúster de Postgres completo, con réplicas primarias y posibles.
Existe un mecanismo de hibernación en el lado de Aurabase, pero tiene un propósito diferente. En caso de inactividad prolongada, 7 días de forma predeterminada y configurable a través de una variable de entorno, umbral verificado en el código, el aprovisionador pone las instancias inactivas en suspensión para liberar recursos, no para optimizar la latencia del uso intermitente. Al despertar un clúster CNPG inactivo se recrean sus pods a partir de volúmenes persistentes, un mecanismo estructuralmente más pesado que un simple reinicio de proceso sin servidor.
Aurabase no ha publicado ninguna cifra de latencia de activación hasta la fecha, ni para afirmar un tiempo de activación rápido ni para compararlo con Neon. No es el mismo producto y sería deshonesto hacerlo pasar como tal sin las medidas publicadas.
Esta arquitectura dedicada tiene una contraparte directa en términos de aislamiento y previsibilidad del rendimiento: un proyecto no comparte su cómputo con otro proyecto, a diferencia de un clúster compartido de tamaño deficiente. Detallamos este arbitraje en un artículo dedicado: base dedicada versus compartida, impacto real en el rendimiento y el aislamiento.
Elija según su caso de uso
El modelo sin servidor de Neon sirve para un caso de uso específico: muchos entornos efímeros o entornos con tráfico muy intermitente, donde pagar por una computadora que se ejecuta continuamente no tiene sentido económico. Una base de datos por rama de Git, un entorno de vista previa mediante pull request, un prototipo probado varias veces por semana: el arranque en frío ocasional se convierte en un compromiso aceptable frente a una factura proporcional al uso real.
Por el contrario, una arquitectura Postgres dedicada y siempre activa se vuelve preferible cuando la latencia de la primera conexión debe seguir siendo predecible: una API de producción con tráfico regular, un backend que no puede permitirse un pico de latencia ocasional ante una solicitud de usuario o un sistema donde p99 importa más que el costo de una rama de prueba aislada.
| Proveedor | Modelo de cálculo | Activador del sueño | Despertador típico |
|---|---|---|---|
| Neón | Computación sin servidor separada del almacenamiento | Inactividad, desde 5 min (plan gratuito) | Automático, subsegundo a segundos (editor reclamado) |
| Vercel Postgres | Infraestructura de neón (asociación) | Igual que el neón | Igual que el neón |
| Supabase | Organismo dedicado por proyecto | Inactividad prolongada, solo plan gratuito | Manual, restaurar desde el tablero |
| Aurabase | Clúster CNPG dedicado o compartido | Inactividad extendida, 7 días por defecto | No pretende ser subsegundo, no publicado |
Neon Alarm Clock: orden de magnitud documentado por el editor, no auditado de forma independiente. Umbral de hibernación de Aurabase: marcado aura-provisioner, variable HIBERNATE_INACTIVITY_DAYS, predeterminado 7 días.
Preguntas frecuentes
que recordar
El arranque en frío sin servidor de Postgres no es un concepto universal: es una consecuencia directa de la arquitectura Neon, que separa el almacenamiento y el cálculo para suspender este último entre dos usos. Vercel Postgres lo hereda directamente a través de su asociación con Neon. Supabase y Aurabase, que proporcionan instancias dedicadas de Postgres, exponen un mecanismo diferente, medido en días en lugar de minutos, no diseñado para el mismo propósito.
Antes de elegir un proveedor basándose únicamente en este criterio, verifique tres cosas: el umbral de inactividad real documentado por el proveedor, si es configurable en su plan y si el tráfico de su aplicación justifica la suspensión informática. Para su uso con tráfico intermitente real, ramas de prueba o vistas previas, el modelo sin servidor tiene un claro beneficio económico. Para la producción con tráfico regular, una arquitectura dedicada simplemente elimina la cuestión.