Como a Arquitetura Lakebase da Neon Sobrevive a Quedas da AWS: Computação sem Estado e Isolamento Celular

A Neon elimina essa dependência movendo todo o estado durável para uma camada de armazenamento separada e redundante entre zonas. Os nós de computação do Postgres na Neon não armazenam nenhum dado no disco local; eles processam consultas e transmitem registros de WAL para uma frota de nós safekeeper e pageserver, que armazenam cada mudança de forma durável . Isso significa que a falha de um nó de computação interrompe o processamento de consultas momentaneamente, mas nenhum dado é perdido. Uma nova instância de computação pode se conectar ao mesmo histórico de armazenamento e retomar de onde a anterior parou, sem esperar pela recolocação de volumes ou recuperação de crash .

A consequência prática durante uma pane de provisionamento na AWS é significativa: a Neon não precisa fazer chamadas às APIs da EC2 em um momento de falha para repor nós de computação inativos. Ela pode simplesmente puxar uma instância substituta de um pool já aquecido de máquinas em execução e conectá-la ao estado de armazenamento existente. A falha no plano de controle do provedor se torna um inconveniente operacional, não uma emergência de disponibilidade de dados.

Isolamento baseado em células: uma região não significa um único domínio de falha

As implantações regionais da Neon não são monolíticas. Cada região é composta por uma ou mais células de formato idêntico, onde uma célula agrupa seu próprio plano de controle Kubernetes, pool de computação e recursos de armazenamento . Essa compartimentalização significa que uma falha em uma célula — seja causada por uma pane no provedor, um bug de software ou esgotamento de recursos — não se propaga para outras células na mesma região.

Durante a interrupção da AWS em maio de 2026 na us-east-1, a falha do provedor afetou especificamente sua capacidade de provisionar novas instâncias e alocar endereços de IP . Para uma arquitetura de célula única, isso teria sido um incidente em toda a região. No design baseado em células da Neon, apenas as células que esgotaram seus buffers de computação pré-provisionados foram afetadas. Outras células, com buffers suficientes de instâncias já alocadas, continuaram operando sem interrupção .

Este resultado reflete uma escolha de design deliberada: as células são dimensionadas para que os limites de recursos de nenhuma delas possam se tornar um gargalo regional. Lições arquiteturais anteriores reforçaram esse pensamento. Antes de migrar para o isolamento celular, a Neon operava um único cluster Kubernetes por região, e os testes mostraram uma degradação do serviço além de 10.000 bancos de dados simultâneos devido a limites de memória do etcd do EKS, restrições de configuração de rede e limitação de taxa da API do Kubernetes . A arquitetura baseada em células elimina totalmente esses tetos, dividindo a carga entre clusters independentes e não comunicantes.

Reduzindo a dependência do provedor por meio de pré-provisionamento e virtualização própria

O relacionamento da Neon com o provedor de nuvem é intencionalmente distanciado. Em vez de chamar as APIs da EC2 sob demanda sempre que um banco de dados precisar ser iniciado, a Neon pré-aloca pools de instâncias grandes — muitas vezes bare-metal — e mantém uma capacidade de buffer para absorver interrupções de provisionamento . Esse buffer não é um pequeno warm pool para clientes prioritários; é um componente estrutural de como o sistema agenda a computação.

Sobre essas instâncias pré-provisionadas, a Neon executa sua própria camada de virtualização com escalonamento vertical, que empacota múltiplas instâncias do Postgres em um único host físico. Isso contorna duas dependências do provedor ao mesmo tempo: a API de provisionamento de VMs (as instâncias já estão rodando) e o caminho de conexão ao armazenamento em bloco (os nós de computação da Neon não usam volumes de bloco na nuvem) .

A durabilidade dos dados segue o mesmo padrão. Todo o conteúdo do banco de dados reside no próprio serviço de armazenamento com resiliência de zona da Neon, respaldado por armazenamento de objetos como Amazon S3 ou Azure Blob Storage, em vez de dispositivos de bloco do provedor . As APIs de armazenamento de objetos possuem modos de falha diferentes das APIs de provisionamento de VMs e, na prática, a durabilidade do armazenamento de objetos durante panes no plano de controle regional tem se mostrado significativamente mais resiliente. Quando um nó pageserver ou safekeeper falha, nenhum estado durável é perdido — outro nó pode reconstruir as páginas necessárias a partir do WAL e do armazenamento de objetos .

Armazenamento redundante por zona é a fundação, não um adicional premium

Em muitos serviços de banco de dados gerenciados, a replicação de armazenamento em múltiplas zonas de disponibilidade (Multi-AZ) é um recurso pago que exige configuração explícita. Na Neon, todo banco de dados — independentemente do plano — é respaldado por armazenamento de objetos distribuído e com redundância entre zonas, com caches SSD NVMe espalhados por múltiplas zonas de disponibilidade . Isso elimina a replicação física entre zonas como uma preocupação separada, porque a própria camada de armazenamento é inerentemente replicada.

O design de replicação do WAL fornece garantias concretas de durabilidade: as escritas são replicadas de forma síncrona para os safekeepers com um requisito de quórum (uma configuração publicada é a replicação de seis vias com um quórum de escrita de quatro em seis), o que significa que uma zona de disponibilidade inteira mais uma réplica adicional podem falhar sem perda de dados . Isso não é resiliência teórica; é uma propriedade do caminho de escrita que deve ser satisfeita antes que as transações sejam confirmadas para o cliente.

Para a disponibilidade de computação especificamente, o modelo de armazenamento compartilhado oferece uma vantagem que as arquiteturas tradicionais de primário-réplica não conseguem igualar: como todas as instâncias de computação compartilham o mesmo histórico de armazenamento durável, uma computação substituta não precisa se atualizar por meio de replicação física. Ela se conecta ao histórico existente e começa a servir consultas em segundos ou poucos minutos, dependendo da carga de trabalho e do tamanho do conjunto de trabalho em cache .

Metas de disponibilidade e o que os dados mostram

Os SLIs de disponibilidade publicados para a arquitetura lakebase da Neon se situam na faixa aproximada de 99,93% a 99,96% . Esses números refletem um design onde as falhas de computação são recuperadas substituindo nós sem estado, em vez de fazer failover para réplicas quentes ociosas, e onde a durabilidade do armazenamento é alcançada por replicação baseada em armazenamento de objetos, em vez de espelhamento de disco síncrono.

O próprio histórico de incidentes da Neon fornece uma calibragem útil dessas metas. Um incidente de maio de 2025 em us-east-1 causou 5,5 horas de indisponibilidade para operações de início e criação de bancos de dados em dois eventos separados, embora os bancos de dados ativos não tenham sido afetados . A causa raiz — esgotamento de endereços IP nas sub-redes do Kubernetes, desencadeado por sobrecarga do plano de controle e má configuração do AWS CNI — expôs um limite de escala que a arquitetura baseada em células foi posteriormente projetada para prevenir . Anteriormente, em agosto de 2024, uma pane no pageserver em us-east-1 afetou aproximadamente 0,4% dos projetos de clientes por até 2 horas, após a falha de uma instância EC2. Como os pageservers atuam como um cache de disco local respaldado pelo S3, perder um pageserver significou indisponibilidade temporária, em vez de perda permanente de dados .

Esses incidentes ressaltam que a computação sem estado e o armazenamento compartilhado reduzem a gravidade das falhas, mas não as eliminam completamente. As propriedades de resiliência da arquitetura — nenhuma perda de dados por falhas de computação, recuperação automática através da reconexão, raio de impacto contido pela célula — se mantêm sob condições reais de falha, mas o sistema não é imune a defeitos de software, esgotamento de recursos ou dependências do provedor de nuvem que ainda não foram totalmente desacopladas (como a alocação de endereços IP).

Testes de resiliência: como a Neon valida o design

O blog de engenharia da Neon afirma que o sistema é testado contra cenários de falha do mundo real, incluindo interrupções de provisionamento do provedor de nuvem e simulações de desconexão de zonas de disponibilidade inteiras . Esses testes exercitam os buffers de instâncias pré-provisionadas e os limites de isolamento celular que deveriam limitar o raio de impacto. A forma geral de engenharia do caos que a Neon descreve espelha uma prática estabelecida: definir uma hipótese de estado estável sobre como o sistema deve se comportar sob falha, injetar uma falha controlada (como desconectar uma AZ inteira ou esgotar os buffers de computação), observar se a hipótese se mantém e iterar na arquitetura quando isso não acontece .

Embora a Neon não tenha publicado uma metodologia detalhada de engenharia do caos ou resultados de experimentos específicos além da visão geral do blog arquitetural, a evidência disponível mostra que os testes visam diretamente as alegações de resiliência distintivas do sistema. Os testes descritos — simulando interrupções de provisionamento e falhas de AZ — são precisamente os cenários em que a computação sem estado e o isolamento celular devem fornecer a maior vantagem sobre as arquiteturas tradicionais de banco de dados gerenciado. A interrupção da AWS em maio de 2026 serviu efetivamente como uma validação não planejada desses mesmos mecanismos, e o resultado de impacto contido é consistente com o que o pré-provisionamento e o isolamento celular foram projetados para produzir.

O que isso significa para equipes que avaliam o Postgres serverless

A arquitetura da Neon oferece uma troca de resiliência específica: ela aceita que a computação é efêmera e a substitui rapidamente, em vez de mantê-la rodando a todo custo, enquanto investe pesadamente na durabilidade do armazenamento e no isolamento de domínios de falha. Para cargas de trabalho em que interrupções ocasionais de consultas por menos de um minuto são aceitáveis e a principal preocupação é a segurança dos dados, este modelo elimina o custo e a complexidade de manter réplicas de prontidão. Para cargas de trabalho que exigem disponibilidade de consulta contínua com zero interrupção, configurações adicionais de múltiplas computações estão disponíveis, mas com um custo mais alto.

A arquitetura também força uma contabilidade honesta da dependência da nuvem. Nenhum serviço de banco de dados é verdadeiramente independente de seu provedor de nuvem subjacente, mas o grau de acoplamento varia enormemente. A decisão da Neon de pré-provisionar capacidade, usar sua própria camada de virtualização e armazenar dados em armazenamento de objetos em vez de volumes de bloco reduz a superfície de APIs do provedor que precisam estar disponíveis para o funcionamento da camada de banco de dados. Essa superfície de dependência mais estreita valeu a pena durante a interrupção da AWS de maio de 2026, quando as células com buffers pré-provisionados adequados continuaram operando, superando uma falha que teria sido regional para uma arquitetura mais fortemente acoplada.

Para equipes que constroem sobre infraestrutura serverless, a abordagem da Neon demonstra que a contenção do raio de impacto não é uma reflexão tardia — é um produto de decisões arquiteturais tomadas na fronteira entre armazenamento e computação, e na estrutura do domínio de falha, muito antes de uma pane ocorrer.