La arquitectura Lakebase de Neon: cómo el cómputo sin estado y las celdas de aislamiento sobreviven a las interrupciones de AWS

La consecuencia práctica durante una interrupción del aprovisionamiento de AWS es significativa: Neon no necesita llamar a las API de EC2 bajo presión de fallo para reemplazar nodos de cómputo muertos. Puede tomar un reemplazo de un grupo precalentado de instancias ya en ejecución y conectarlo al estado de almacenamiento existente. El deterioro del plano de control del proveedor de nube se convierte en una molestia operativa y no en una emergencia de disponibilidad de datos.

Aislamiento basado en celdas: una región no equivale a un solo dominio de fallo

Los despliegues regionales de Neon no son monolíticos. Cada región se compone de una o más celdas de idéntica forma, donde una celda agrupa su propio plano de control de Kubernetes, su grupo de cómputo y sus recursos de almacenamiento . Esta compartimentación implica que un fallo en una celda —ya sea provocado por una interrupción del proveedor de nube, un error de software o el agotamiento de recursos— no se propaga a otras celdas de la misma región.

Durante la interrupción de AWS de mayo de 2026 en us-east-1, el fallo del proveedor afectó específicamente a su capacidad para aprovisionar nuevas instancias y asignar direcciones IP . Para una arquitectura de celda única, eso habría sido un incidente regional. En el diseño basado en celdas de Neon, solo las celdas que agotaron sus reservas de cómputo preaprovisionadas se vieron afectadas. Otras celdas, que mantenían suficientes reservas de instancias ya asignadas, siguieron funcionando sin interrupción .

Este resultado es fruto de una decisión de diseño deliberada: las celdas se dimensionan de modo que los límites de recursos de una sola celda no puedan convertirse en un cuello de botella regional. Lecciones arquitectónicas anteriores reforzaron esta idea. Antes de adoptar el aislamiento por celdas, Neon operaba un único clúster de Kubernetes por región, y las pruebas mostraron degradación del servicio a partir de las 10 000 bases de datos concurrentes debido a los límites de memoria de etcd en EKS, restricciones de configuración de red y la limitación de tasa de la API de Kubernetes . La arquitectura basada en celdas elimina por completo esos techos de clúster único al repartir la carga entre celdas independientes que no interactúan entre sí.

Reducir la dependencia del proveedor de nube mediante preaprovisionamiento y virtualización a medida

La relación de Neon con el proveedor de nube subyacente es deliberadamente distante. En lugar de llamar a las API de EC2 bajo demanda cada vez que hay que arrancar una base de datos, Neon preasigna grupos de instancias grandes —a menudo de tipo ‘bare-metal’— y mantiene un colchón de capacidad para absorber interrupciones del aprovisionamiento . Este colchón no es un pequeño grupo templado para clientes prioritarios; es un componente estructural de cómo el sistema planifica el cómputo.

Sobre estas instancias preaprovisionadas, Neon ejecuta su propia capa de virtualización con autoescalado vertical que empaqueta múltiples instancias de Postgres en un único host físico. Esto elude dos dependencias del proveedor de nube simultáneamente: la API de aprovisionamiento de máquinas virtuales (las instancias ya están en marcha) y la ruta de conexión del almacenamiento en bloque (los nodos de cómputo de Neon no usan volúmenes de bloque en la nube) .

La durabilidad de los datos sigue el mismo patrón. Todo el contenido de la base de datos reside en el propio servicio de almacenamiento resiliente por zonas de Neon, respaldado por almacenes de objetos como Amazon S3 o Azure Blob Storage, en lugar de en dispositivos de bloque del proveedor de nube . Las API de almacenamiento de objetos tienen modos de fallo diferentes a los de las API de aprovisionamiento de máquinas virtuales y, en la práctica, la durabilidad del almacén de objetos durante interrupciones regionales del plano de control ha demostrado ser significativamente más resistente. Cuando un nodo ‘pageserver’ o ‘safekeeper’ falla, no se pierde ningún estado duradero: otro nodo puede reconstruir las páginas necesarias a partir del WAL y del almacenamiento de objetos .

El almacenamiento redundante por zonas es la base, no un complemento de pago

En muchos servicios de base de datos gestionados, la replicación del almacenamiento en múltiples zonas de disponibilidad (multi-AZ) es una característica de pago que requiere configuración explícita. En Neon, cada base de datos —independientemente del plan de precios— se apoya en almacenamiento de objetos distribuido y redundante por zonas, con cachés SSD NVMe repartidas en varias zonas de disponibilidad . Esto elimina la replicación física entre zonas como una preocupación separada, porque la propia capa de almacenamiento ya es inherentemente replicada.

El diseño de replicación del WAL ofrece garantías de durabilidad concretas: las escrituras se replican sincrónicamente a los ‘safekeepers’ con un requisito de cuórum (la replicación en seis vías con un cuórum de escritura de cuatro sobre seis es una configuración publicada), lo que significa que una zona de disponibilidad entera más una réplica adicional pueden perecer sin pérdida de datos . Esto no es resiliencia teórica; es una propiedad de la ruta de escritura que debe cumplirse antes de confirmar las transacciones al cliente.

En lo que respecta específicamente a la disponibilidad del cómputo, el modelo de almacenamiento compartido ofrece una ventaja que las arquitecturas tradicionales de principal-réplica no pueden igualar: dado que todas las instancias de cómputo comparten el mismo historial de almacenamiento duradero, un cómputo de reemplazo no necesita ponerse al día mediante replicación física. Se conecta al historial existente y empieza a atender consultas en un plazo de segundos a unos pocos minutos, según la carga de trabajo y el tamaño del conjunto de trabajo cacheado .

Objetivos de disponibilidad y qué muestran los datos

Los SLI de disponibilidad publicados para la arquitectura ‘lakebase’ de Neon se sitúan en el rango aproximado de 99,93 % a 99,96 % . Estas cifras reflejan un diseño en el que los fallos de cómputo se recuperan reemplazando nodos sin estado en lugar de conmutar a ‘hot standbys’ inactivos, y donde la durabilidad del almacenamiento se logra mediante replicación respaldada por almacén de objetos, en vez de duplicación síncrona de discos.

El propio registro de incidentes de Neon proporciona una calibración útil de estos objetivos. Un incidente de mayo de 2025 en us-east-1 causó 5,5 horas de indisponibilidad para las operaciones de inicio y creación de bases de datos a lo largo de dos eventos separados, aunque las bases de datos activas no se vieron afectadas . La causa raíz —el agotamiento de direcciones IP en las subredes de Kubernetes provocado por una sobrecarga del plano de control y una mala configuración del CNI de AWS— dejó al descubierto un límite de escala que la arquitectura basada en celdas se diseñó posteriormente para prevenir . Anteriormente, en agosto de 2024, una interrupción de ‘pageserver’ en us-east-1 afectó aproximadamente al 0,4 % de los proyectos de clientes durante un máximo de dos horas, tras un fallo en una instancia EC2. Dado que los ‘pageservers’ actúan como una caché de disco local respaldada por S3, perder un ‘pageserver’ significó indisponibilidad temporal, no una pérdida permanente de datos .

Estos incidentes subrayan que el cómputo sin estado y el almacenamiento compartido reducen la gravedad de los fallos, pero no los eliminan por completo. Las propiedades de resiliencia de la arquitectura —ausencia de pérdida de datos por fallos de cómputo, recuperación automática mediante reconexión, radio de explosión acotado por celdas— se mantienen bajo condiciones de fallo reales, pero el sistema no es inmune a defectos de software, agotamiento de recursos o dependencias del proveedor de nube que aún no se han desacoplado por completo (como la asignación de direcciones IP).

Pruebas de resiliencia: cómo valida Neon el diseño

El blog de ingeniería de Neon afirma que el sistema se prueba contra escenarios de fallo del mundo real, incluyendo interrupciones del aprovisionamiento del proveedor de nube y simulaciones de desconexión de una zona de disponibilidad completa . Estas pruebas ejercitan las reservas de instancias preaprovisionadas y los límites de aislamiento de celdas que se supone que limitan el radio de explosión. La forma general de la ingeniería del caos que Neon describe refleja la práctica establecida: definir una hipótesis de estado estable sobre cómo debería comportarse el sistema bajo fallo, inyectar un fallo controlado (como desconectar una zona de disponibilidad entera o agotar las reservas de cómputo), observar si la hipótesis se mantiene e iterar sobre la arquitectura cuando no es así .

Aunque Neon no ha publicado una metodología detallada de ingeniería del caos ni resultados de experimentos específicos más allá de la descripción general del blog de arquitectura, la evidencia disponible muestra que las pruebas apuntan directamente a las afirmaciones de resiliencia distintivas del sistema. Las pruebas que Neon describe —simular interrupciones del aprovisionamiento y fallos de zonas de disponibilidad— son precisamente los escenarios en los que el cómputo sin estado y el aislamiento por celdas deberían proporcionar la mayor ventaja sobre las arquitecturas de bases de datos gestionadas tradicionales. La interrupción de AWS de mayo de 2026 sirvió efectivamente como una validación no planificada de esos mismos mecanismos, y el resultado de radio de explosión contenido es coherente con lo que el preaprovisionamiento y el aislamiento por celdas están diseñados para producir.

Qué significa esto para los equipos que evalúan Postgres sin servidor

La arquitectura de Neon ofrece una compensación de resiliencia específica: acepta que el cómputo es efímero y lo reemplaza rápidamente en lugar de mantenerlo en funcionamiento a toda costa, al tiempo que invierte fuertemente en durabilidad del almacenamiento y aislamiento del dominio de fallo. Para cargas de trabajo en las que una interrupción ocasional de consultas de menos de un minuto es aceptable y la principal preocupación es la seguridad de los datos, este modelo elimina el coste y la complejidad de mantener ‘hot standbys’. Para cargas de trabajo que requieren disponibilidad continua de consultas sin interrupción alguna, existen configuraciones adicionales de múltiples cómputos, pero conllevan un coste más alto.

La arquitectura también exige una contabilidad honesta de la dependencia de la nube. Ningún servicio de base de datos es verdaderamente independiente de su proveedor de nube subyacente, pero el grado de acoplamiento varía enormemente. La decisión de Neon de preaprovisionar capacidad, usar su propia capa de virtualización y almacenar datos en almacenamiento de objetos en lugar de en volúmenes de bloque reduce la superficie de API del proveedor de nube que deben estar disponibles para que el nivel de base de datos funcione. Esa superficie de dependencia más estrecha dio sus frutos durante la interrupción de AWS de mayo de 2026, cuando las celdas con reservas preaprovisionadas adecuadas siguieron operando durante un fallo que habría sido regional para una arquitectura más estrechamente acoplada.

Para los equipos que construyen sobre infraestructura sin servidor, el enfoque de Neon demuestra que la contención del radio de explosión no es una ocurrencia tardía: es el producto de decisiones arquitectónicas tomadas en el límite entre almacenamiento y cómputo, así como en la estructura del dominio de fallo, mucho antes de que ocurra una interrupción.