Supavisor Connection Pooler: Prevenindo a Exaustão do Postgres
O maior calcanhar de Aquiles das arquiteturas Serverless modernas (Vercel, AWS Lambda) não é a velocidade do frontend, mas sim a forma violenta como elas atacam o banco de dados relacional.
O Postgres foi desenhado na década de 90 para um mundo onde um servidor monolítico abria 50 conexões TCP e as mantinha abertas para sempre. O mundo Serverless funciona abrindo 5.000 instâncias efêmeras simultaneamente. Sem proteção, o banco de dados entra em colapso.
A solução obrigatória do Supabase para esse problema é o Supavisor.
1. O Problema: Exaustão de Conexões (TCP Handshake)
Abrir uma conexão direta com o Postgres (postgres://user:pass@host:5432/db) é caro. Exige negociação TCP, criptografia SSL e alocação de memória no servidor do banco.
Se você colocar uma URL da porta 5432 diretamente em uma Edge Function ou Server Action do Next.js de um SaaS B2B lotado, cada usuário apertando F5 tentará criar sua própria ponte TCP.
Em questão de segundos, você ultrapassa o limite do banco (geralmente entre 100 e 500 conexões ativas) e os usuários começam a receber o terrível erro de infraestrutura: FATAL: sorry, too many clients already.
2. A Proteção: Supavisor Connection Pooler
O Supabase construiu o Supavisor (um pooler nativo escrito em Elixir) que atua como um pedágio inteligente à frente do Postgres.
Em vez das funções serverless conectarem diretamente no banco, elas conectam no Pooler. O Pooler mantém um pequeno número seguro de conexões abertas com o banco (ex: 50 conexões) e enfileira/divide essas conexões com as 5.000 requisições do frontend.
A Regra de Ouro (Porta 6543 vs 5432)
Ao utilizar o cliente do Supabase ou Prisma, você tem duas strings de conexão no seu painel:
- Direct Connection (Porta 5432): Conexão IPv6 direta. NUNCA USE ISSO no seu código Serverless da Vercel ou Supabase Edge Functions. Use apenas para conexões contínuas de longa duração (como um microsserviço Node.js que nunca desliga, ferramentas de BI ou migrações do Prisma).
- Connection Pooling (Porta 6543): Conexão roteada pelo Supavisor. SEMPRE USE ESTA para Server Actions, APIs do Next.js e conexões efêmeras (Transaction Mode). Ela protege o seu banco do efeito "manada".
3. Transaction vs Session Mode
O Supavisor suporta diferentes modos de pool, e saber qual usar é crítico:
- Transaction Mode (Padrão para Serverless): A conexão com o banco é devolvida ao pool assim que a query específica (SELECT/INSERT) termina, mesmo que o script continue rodando. Isso é perfeito para Vercel e garante a maior capacidade de escalabilidade possível.
- Session Mode: A conexão com o banco fica presa à requisição até que o usuário (ou a função serverless) desconecte explicitamente. Cuidado: em picos de tráfego, sessões longas no Session Mode podem esgotar o pool rapidamente.
[!WARNING] Cuidado com IPv4! Desde 2024, provedores de nuvem estão descontinuando IPv4 para bancos. O Supabase fornece o IPv4 Pooler como um add-on pago. Se o seu projeto estiver hospedado na Vercel, você não precisa do IPv4, pois a infraestrutura moderna suporta nativamente IPv6 via Pooler na porta 6543.
Precisa de apoio técnico para a sua empresa?
Se a sua operação busca especialistas para modernização de sistemas legados ou desenvolvimento de sistemas sob medida com arquitetura de alta performance (Next.js e Supabase), conheça meus serviços de tecnologia ou fale diretamente comigo pelo WhatsApp.