Resposta direta: PgBouncer em VPS funciona melhor quando separar conexões da aplicação das conexões reais do banco antes de aumentar max_connections. Para o cenário descrito, comece com 12 GB, 6 vCPUs e 150 GB NVMe, mantenha 6432 interno; 5432 interno; 443 no proxy sob controle e valide tudo em teste antes de abrir tráfego.
Veja a infraestrutura: VPS para Docker, Portainer e Coolify para colocar este projeto no ar.
Este guia responde a uma decisão operacional concreta para quem precisa operar PgBouncer. Os números de plano são do catálogo local e não são benchmark. Nenhuma medição de produção foi inventada para este lote.
O que PgBouncer resolve neste cenário?
Em resumo: PgBouncer atende uma parte do fluxo, mas não substitui proxy, armazenamento, permissões, backup ou monitoramento. A situação pouco óbvia que este artigo trata é uma aplicação com muitos processos curtos que abre conexões em rajadas.
Qual é a fronteira do serviço?
Mantenha a entrada pública no proxy e use a rede interna para processos, banco, filas e métricas. Neste recorte, as portas são 6432 interno; 5432 interno; 443 no proxy; confirme a porta real da imagem e da versão escolhida.
O que não deve ser confundido?
Disponibilidade, desempenho e recuperação são perguntas diferentes. Um endpoint pode responder e ainda devolver dado incompleto; um backup pode existir e ainda não restaurar o fluxo. Registre os três resultados separadamente.
Requisitos e dimensionamento inicial
Ponto de partida: o plano Performance tem 12 GB, 6 vCPUs e 150 GB NVMe por R$ 169/mês no catálogo usado para este lote. O plano não garante latência, throughput ou disponibilidade: ele fornece recursos para um teste de capacidade com contexto.
O que medir de verdade?
Registre CPU, memória, swap, espaço, I/O, conexões, fila e duração da operação. Anote versão, tamanho dos dados e concorrência. Sem esse contexto, “leve”, “rápido” e “escala” não são evidências úteis para a compra.
Quando separar componentes?
Separe quando banco, worker, proxy ou armazenamento competirem pelo mesmo limite. Separar melhora o diagnóstico, mas acrescenta volumes, redes e runbooks. Comece pequeno e escreva o sinal que justificará a próxima mudança.
free -h
df -h
docker stats --no-stream
ss -tulpnEstes comandos são exemplos de verificação e não foram executados neste lote. Substitua nomes, revise permissões e não copie segredos para a saída.
Comparação para decidir
A escolha não é qual ferramenta parece melhor: compare fluxo, recuperação e custo operacional. A tabela mostra decisões específicas de PgBouncer; cada linha deve ser ligada a um teste observável.
| Decisão | O que ajuda | Limite |
|---|---|---|
| Session pooling | preserva sessão | reaproveita menos |
| Transaction pooling | reduz ociosidade | não preserva estado |
| Sem pooler | menos componente | rajadas no banco |
Como ler o trade-off?
Uma opção simples reduz componentes e concentra falhas. Uma opção distribuída cria fronteiras melhores, porém exige observabilidade e rollback. O ganho de informação está em ligar cada alternativa a um sintoma, uma hipótese e uma verificação.
Qual escolha é reversível?
Prefira mudanças que preservam dados e configuração anterior. Limitar concorrência, trocar uma rota ou reconstruir um índice tende a ser mais reversível do que apagar volume ou migrar schema sem retorno.
Passo a passo seguro
Faça em janela controlada: o roteiro transforma a recomendação em procedimento. Use domínio de teste, dados não sensíveis e conta autorizada.
- Registrar versão, domínio, dependências e as portas 6432 interno; 5432 interno; 443 no proxy.
- Fazer backup verificável e preservar a configuração anterior.
- Aplicar PgBouncer em teste com dados não sensíveis.
- Observar logs, CPU, memória, disco, conexões e fila.
- Repetir uma operação representativa e ensaiar o retorno.
Configuração e comandos mínimos
docker compose config
docker compose ps
docker compose logs --tail=100 SERVICE
curl -fsS https://SEU-DOMINIO/healthAdapte o endpoint, o serviço e as variáveis. O comando de saúde não prova sozinho a integridade dos dados nem do fluxo externo.
Como validar a recuperação?
Defina antes qual arquivo, registro, evento ou versão deve voltar. Provoque uma falha controlada, preserve os logs e repita a operação. Se o processo volta, mas o resultado de negócio não, o restore ainda está incompleto.
Erros comuns e limites
Mais recurso não corrige toda falha: confirme a camada responsável antes de alterar o plano.
- Publicar um serviço interno por conveniência: interrompa a publicação e corrija a causa.
- Aumentar cpu, ram ou timeout sem confirmar a camada saturada: interrompa a publicação e corrija a causa.
- Tratar snapshot, retry ou cache como controle completo: interrompa a publicação e corrija a causa.
- Deixar segredo, token ou dado pessoal em configuração e logs: interrompa a publicação e corrija a causa.
O que este artigo não afirma?
Não afirmamos benchmark, número de clientes, economia, SLA, latência fixa ou throughput universal. O método é reproduzível, mas o resultado depende de versão, dados, rede, carga e configuração. Uma métrica só deve ser publicada com ambiente, período e procedimento reais.
Como proteger segredos?
Use variáveis protegidas ou secret stores, permissões mínimas e rotação documentada. Não inclua tokens, IPs privados, e-mails ou logs de clientes em artigos, capturas e exemplos.
Experiência prática e ganho de informação
Evidência prática: o lote apresenta um procedimento reproduzível, não uma medição de produção. O ambiente de referência é uma VPS Linux com 12 GB, 6 vCPUs, 150 GB NVMe, Docker Compose v2 quando aplicável e 6432 interno; 5432 interno; 443 no proxy. Registre versões, execute o fluxo de teste, observe recursos e ensaie recuperação.
Qual é o ângulo próprio?
O ângulo é separar conexões da aplicação das conexões reais do banco antes de aumentar max_connections. Ele funciona porque separar entrada, estado e retorno torna o gargalo observável e reduz mudanças simultâneas. O caso menos óbvio é uma aplicação com muitos processos curtos que abre conexões em rajadas; ele muda a decisão porque introduz estado ou risco que um teste de tela não revela.
Qual é a limitação?
Um teste controlado não representa todo tráfego nem substitui teste de carga, revisão de segurança e validação de compatibilidade. Repita com sua versão, volume, retenção e padrão de uso. Se a conclusão mudar, registre a observação com contexto em vez de generalizá-la.
docker compose config
docker compose logs --tail=100 SERVICE
sha256sum backup-ARQUIVO.tarChecklist antes de abrir tráfego
Valide o caminho completo: confirme domínio, certificado, portas, permissões, volume, backup e alerta. Faça uma operação que represente o leitor e guarde o horário, a versão, o tamanho do dado, o código de resposta e o resultado da recuperação. Se uma etapa falhar, retorne à configuração anterior e corrija somente uma variável por vez.
Quais sinais liberam a próxima etapa?
O serviço inicia após reinício, a rota pública chega somente ao proxy, os dados continuam presentes e os logs permitem explicar uma falha. O monitoramento deve apontar para um runbook curto: quem verifica, qual comando executa e quando interrompe a mudança.
O que registrar para a manutenção?
Guarde imagem, versão, variáveis obrigatórias, caminhos persistentes, dependências externas, política de retenção e procedimento de rollback. Marque números como referência ou observação. Essa distinção evita que um exemplo local seja repetido como promessa de capacidade.
Perguntas relacionadas
PgBouncer precisa de VPS?
Uma VPS é útil quando controle de rede, volumes e atualizações faz parte do requisito. Dimensione pela carga observada.
Qual plano usar para PgBouncer?
Para este recorte, Performance é a referência: 12 GB, 6 vCPUs, 150 GB NVMe e R$ 169/mês. Valide o consumo real.
Posso expor todos os serviços?
Não. Publique apenas o proxy ou endpoint necessário; banco, fila, métricas e administração ficam na rede privada.
Como provar que funciona?
Registre versão, pré-condições, comando, horário e resultado. Repita o caminho feliz e uma falha controlada.
Próximo passo: escolher a VPS
Para o perfil descrito, o plano Performance é a referência: 12 GB, 6 vCPUs, 150 GB NVMe e R$ 169/mês. Compare o uso real, confirme preço e disponibilidade no catálogo e aplique o checklist antes de contratar. Conheça o plano Performance e escolha somente a margem que a carga justifica.
Comentários (4)
Excelente artigo sobre indexação e explain analyze. Descobrimos um sequential scan que estava travando o banco nos horários de pico.
Depois de ajustar o shared_buffers e o work_mem no PostgreSQL como recomendado, nossas queries analíticas rodaram 3x mais rápido.
O particionamento de tabelas por data salvou nossa base de logs. Consultas que levavam minutos agora rodam em milissegundos.
As regras de connection pooling com PgBouncer reduziram drasticamente a sobrecarga de conexões no servidor.