Este não é um conceito universal, no entanto. Supabase e Aurabase, que provisionam instâncias dedicadas do Postgres, não expõem esse mesmo mecanismo da mesma maneira. Este artigo detalha o que o Neon realmente documenta em sua própria inicialização a frio, como Vercel Postgres e Supabase se comparam e onde o modelo Aurabase se encaixa, verificado diretamente no código do provisionador, em vez de inferido de uma página de marketing.
O essencial
- A inicialização a frio sem servidor refere-se ao atraso adicionado quando um banco de dados suspenso deve ativar sua computação antes de responder à primeira solicitação.
- O Neon separa armazenamento e cálculo: a computação entra em suspensão após um período documentado de inatividade (5 minutos por padrão no plano gratuito, configurável nos planos pagos).
- Neon documenta uma reinicialização normalmente na ordem de algumas centenas de milissegundos a alguns segundos, um número publicado pela editora, mensurável ao vivo por meio da ferramenta comunitária neon-latency-benchmarks.vercel.app.
- Vercel Postgres conta com a infraestrutura Neon: o comportamento de despertar segue a mesma mecânica, sob uma marca diferente.
- Supabase fornece um banco de dados dedicado por projeto, sem inicialização a frio por conexão. Somente o plano gratuito pausa projetos inativos, com restauração manual.
- Aurabase provisiona um banco de dados Postgres dedicado por projeto, cluster CNPG dedicado ou base dedicada em um cluster compartilhado: este não é um modelo Neon serverless, verificado no código do provisionador.
O que é uma inicialização a frio para um banco de dados Postgres sem servidor?
Uma inicialização a frio ocorre quando a computação que executa seu banco de dados foi colocada em suspensão por inatividade e uma nova consulta deve primeiro reiniciá-la antes de ser executada. Esta não é a latência de rede normal de uma conexão TCP/TLS típica: este é o momento de iniciar um novo processo Postgres e restaurar seu estado, mesmo antes de a primeira solicitação começar a ser executada.
O termo vem amplamente da computação sem servidor, onde um ambiente de execução zerado deve ser reiniciado antes de processar uma solicitação, seja uma função de servidor ou um tempo de execução do WebAssembly na borda. Detalhamos esse mecanismo no lado das funções de borda em nosso artigo sobre inicialização a frio do WebAssembly voltado para contêineres. Para um banco de dados, a mecânica é diferente: não é um binário compilado que inicia, mas um servidor Postgres completo que deve reabrir seus arquivos, validar seu estado e então aceitar novas conexões.
1. Login do cliente
Uma solicitação chega em um projeto cuja computação está suspensa.
2. Detecção de sono
A plataforma percebe que a computação não está mais ativa.
3. Reiniciando a computação
O processo Postgres é reiniciado, o estado necessário é restaurado.
4. Solicitação processada
A conexão foi bem-sucedida, a solicitação é executada normalmente.
Ilustração do mecanismo de partida a frio, sequência simplificada, sem valor de tempo medido.
Por que o Neon coloca sua computação para dormir e com que taxa
O Neon separa sua arquitetura de banco de dados em duas camadas distintas: armazenamento persistente, que mantém os dados, e computação, o próprio processo Postgres, que pode ser interrompido e reiniciado de forma independente. Essa separação permite que o Neon suspenda a computação de um projeto inativo sem mexer nos dados e, em seguida, reinicie-o sob demanda, de acordo com sua documentação oficial.
No plano gratuito, o Neon documenta um tempo limite de inatividade padrão de 5 minutos antes de colocar o computador em suspensão. Os planos pagos permitem configurar esse limite ou até mesmo aumentá-lo significativamente para uso com tráfego constante. Este tipo de padrão muda com as atualizações do produto: verifique a documentação do Neon atualizada no momento da leitura ao invés desta figura isolada.
Este design atende a um propósito específico, ambientes efêmeros. Um banco de dados por branch Git, um ambiente de visualização por solicitação pull, um banco de dados de teste que é usado apenas alguns minutos por dia: executar uma computação continuamente para esses usos é caro e não traz nenhum benefício real. Suspender a computação entre dois usos reduz a conta sem excluir os dados, este é o argumento central do modelo serverless do Neon.
Quanto tempo dura um despertador Neon e como verificar você mesmo
Neon indica em sua documentação uma reinicialização de computação normalmente da ordem de algumas centenas de milissegundos a alguns segundos, dependendo do tamanho do projeto e do volume de logs de transações a serem reproduzidos antes que a computação esteja pronta. Este é um número publicado pela própria editora, não uma auditoria independente: trate-o como uma ordem de grandeza documentada, não como uma garantia contratual.
Para medição no mundo real, uma ferramenta pública da comunidade, neon-latency-benchmarks.vercel.app, pesquisa projetos Neon suspensos em intervalos regulares e exibe a latência de ativação observada. Este é o tipo de metodologia que importa mais do que um simples número de documentação: as condições de teste permanecem visíveis, não escondidas atrás de uma média de marketing. Aplicamos o mesmo princípio em nossa própria metodologia de benchmark de backend : publicar o protocolo antes de publicar uma figura.
| Tamanho do projeto | Mais relacionamentos e volume WAL para validar tornam a reinicialização mais demorada. |
|---|---|
| Região e distância da rede | Aumenta a latência da conexão, independente da inicialização a frio em si. |
| Plano de preços | Os planos pagos permitem configurar ou estender o limite de inatividade. |
| Frequência de conexões | Uma computação que permanece solicitada regularmente nunca sofre esse atraso. |
Vercel Postgres e Neon: o mesmo motor com outra marca?
A Vercel construiu sua oferta de banco de dados Postgres com base na infraestrutura Neon, uma parceria tornada pública em 2024. No momento em que este artigo foi escrito, esta integração Postgres era oferecida no Vercel Marketplace como uma opção de armazenamento junto com outros provedores. Confira a página atualizada do produto Vercel: esse tipo de parceria evolui rapidamente em um mercado que muda a cada trimestre.
Concretamente, o comportamento de suspensão e ativação de um banco de dados Postgres provisionado via Vercel segue a mesma mecânica descrita acima diretamente para o Neon. Não é um motor separado com modelo próprio de partida a frio, é a mesma infraestrutura exposta por trás de uma integração Vercel.
O Supabase tem uma partida a frio comparável?
Não, não da mesma maneira. Supabase provisiona uma instância Postgres dedicada por projeto, em vez de uma computação sem servidor suspensa por conexão. Portanto, não há atraso no despertar adicionado a cada nova sessão após alguns minutos de inatividade, ao contrário do modelo Neon.
No entanto, existe um mecanismo diferente no plano gratuito: Supabase documenta uma pausa automática de projetos inativos após um período prolongado, da ordem de uma semana de acordo com sua documentação, com restauração manual a partir do painel em vez de ativação automática na primeira solicitação. É um limite medido em dias, não em minutos, e uma ação explícita em vez de uma recuperação transparente: duas diferenças estruturais com o arranque a frio Neon, não uma simples variação do mesmo mecanismo. Para uma comparação completa da arquitetura, nossa comparação detalhada Aurabase vs Supabase documenta outras discrepâncias.
E o modelo Aurabase: por que a comparação não se aplica como está
Aurabase não oferece um modelo sem servidor como o Neon. Verificado no código do provisionador (aura-provisioner, código aberto em github.com/daylami555/aurabase): cada projeto recebe um cluster Postgres dedicado gerenciado pela CloudNativePG, a operadora CNPG do Kubernetes, ou uma base dedicada em um cluster CNPG compartilhado entre vários projetos da mesma organização, dependendo do plano escolhido. Em ambos os casos, não é uma única computação que suspende e ativa a cada conexão: é um cluster Postgres completo, com réplicas primárias e possíveis.
Existe um mecanismo de hibernação no lado do Aurabase, mas serve a um propósito diferente. Na inatividade prolongada, 7 dias por padrão e configurável por meio de uma variável de ambiente, limite verificado no código, o provisionador coloca as instâncias inativas em suspensão para liberar recursos, não para otimizar a latência de uso intermitente. Ativar um cluster CNPG adormecido recria seus pods a partir de volumes persistentes, um mecanismo estruturalmente mais pesado do que uma simples reinicialização de processo sem servidor.
Aurabase não divulgou nenhum número de latência de despertar até o momento, nem para reivindicar um tempo de despertar rápido, nem para compará-lo com o Neon. Não é o mesmo produto e seria desonesto considerá-lo como tal sem medições publicadas.
Esta arquitetura dedicada tem uma contrapartida direta em termos de isolamento e previsibilidade de desempenho: um projeto não compartilha sua computação com outro projeto, ao contrário de um cluster compartilhado de tamanho insuficiente. Detalhamos essa arbitragem em um artigo dedicado: base dedicada vs compartilhada, impacto real no desempenho e isolamento.
Escolha de acordo com seu caso de uso
O modelo sem servidor Neon atende a um caso de uso específico: muitos ambientes efêmeros ou ambientes com tráfego muito intermitente, onde pagar por uma computação que funciona continuamente não faz sentido do ponto de vista econômico. Um banco de dados por branch Git, um ambiente de visualização por solicitação pull, um protótipo testado algumas vezes por semana: a inicialização a frio ocasional torna-se um compromisso aceitável contra uma fatura proporcional ao uso real.
Por outro lado, uma arquitetura Postgres dedicada e sempre ativa torna-se preferível sempre que a latência da primeira conexão precisa permanecer previsível: uma API de produção com tráfego regular, um back-end que não pode permitir um pico ocasional de latência em uma solicitação do usuário ou um sistema onde o p99 é mais importante do que o custo de uma ramificação de teste isolada.
| Fornecedor | Modelo de cálculo | Gatilho de sono | Despertador típico |
|---|---|---|---|
| Néon | Computação sem servidor separada do armazenamento | Inatividade, a partir de 5 min (plano gratuito) | Automático, de subsegundos a segundos (editor reivindicado) |
| Vercel Postgres | Infraestrutura Neon (parceria) | O mesmo que néon | O mesmo que néon |
| Supabase | Corpo dedicado por projeto | Inatividade prolongada, apenas plano gratuito | Manual, restaurar do painel |
| Aurabase | Cluster CNPG dedicado ou compartilhado | Inatividade prolongada, 7 dias por padrão | Não pretendido como subsegundo, não publicado |
Neon Alarm Clock: ordem de grandeza documentada pela editora, não auditada de forma independente. Limite de hibernação do Aurabase: verificado em aura-provisioner, variável HIBERNATE_INACTIVITY_DAYS, padrão 7 dias.
Perguntas frequentes
O que lembrar
A inicialização a frio sem servidor do Postgres não é um conceito universal: é uma consequência direta da arquitetura Neon, que separa armazenamento e cálculo para suspender este último entre dois usos. Vercel Postgres o herda diretamente por meio de sua parceria com a Neon. Supabase e Aurabase, que fornecem instâncias dedicadas do Postgres, expõem um mecanismo diferente, medido em dias em vez de minutos, não projetado para o mesmo propósito.
Antes de escolher um provedor apenas com base neste critério, verifique três coisas: o limite real de inatividade documentado pelo provedor, se ele é configurável em seu plano e se o tráfego do seu aplicativo justifica a suspensão da computação. Para uso com tráfego intermitente real, ramificações de teste ou visualizações, o modelo sem servidor tem um claro benefício econômico. Para produção com tráfego regular, uma arquitetura dedicada simplesmente elimina a questão.