O que é PgDog

PgDog é um proxy é connection pooler para PostgreSQL, escrito em Rust, open source é com foco em alto desempenho. Ele foi anunciado publicamente em junho de 2026 é rapidamente chamou atenção da comunidade no Hacker News, chegando a mais de 480 pontos é quase 230 comentários em poucas horas.

A ideia central é simples: em aplicações que abrem é fecham conexões com o banco o tempo todo, manter um pool de conexões prontas reduz latência é alivia o PostgreSQL. O PgDog entra nessa camada, mas vai além do pooling básico: ele atua como proxy inteligente, com suporte a roteamento de queries, failover é balanceamento de carga entre réplicas.

O projeto nasceu como resposta às limitações do PgBouncer, que existe há mais de 15 anos é tem arquitetura de thread única. PgDog usa threads é async Rust para aproveitar múltiplos núcleos de CPU, o que faz diferença em servidores modernos com 8, 16 ou mais cores.

Como funciona

PgDog fica entre a sua aplicação é o PostgreSQL. A aplicação aponta para o PgDog (ex: localhost:6432) em vez de apontar direto para o banco (porta 5432). O PgDog recebe as conexões, mantém um pool interno de conexões abertas com o Postgres é reutiliza essas conexões para múltiplos clientes.

Internamente, ele usa o protocolo nativo do PostgreSQL (wire protocol), então é transparente para qualquer cliente: não precisa de driver especial, funciona com psycopg2, libpq, node-postgres, JDBC é todos os outros. A aplicação não sabe que está falando com um proxy.

O diferencial técnico é que PgDog analisa as queries antes de encaminhar. Com essa análise, ele consegue rotear SELECTs para réplicas de leitura automaticamente é INSERTs/UPDATEs para o primário. Isso é o que ferramentas como HAProxy não conseguem fazer sozinhas, porque não entendem SQL.

Principais recursos

Os recursos que fazem PgDog se destacar dos concorrentes mais antigos:

  • Connection pooling com múltiplos modos: session pooling (uma conexão de banco por sessão de cliente), transaction pooling (compartilha conexões entre transações) é statement pooling (compartilha por statement).
  • Roteamento automático de leitura/escrita: queries SELECT vão para réplicas, mutations vão para o primário - sem mudar nada na aplicação.
  • Balanceamento de carga entre réplicas: distribui a carga de leitura entre múltiplas réplicas configuradas.
  • Failover automático: detecta falha no primário é redireciona automaticamente.
  • TLS/SSL: suporte completo para conexões criptografadas entre cliente-PgDog é PgDog-banco.
  • Configuração em TOML: arquivo de configuração simples é legível.
  • Métricas é observabilidade: expõe métricas de conexões, latência é erros.

A combinação de pooling mais roteamento SQL é o que justifica o interesse: antes precisava de duas ferramentas separadas (PgBouncer mais HAProxy ou PgBouncer mais Patroni) para ter isso tudo.

Como começar: instalação passo a passo

PgDog é distribuído como binário pré-compilado para Linux (x86_64 é ARM64) é também pode ser compilado do zero com Rust. Para testar rápido, a opção mais simples é baixar o binário ou usar Docker.

Via Docker (mais rápido para testar):

  • 1. Crie um arquivo pgdog.toml com a configuração (veja abaixo)
  • 2. Execute: Docker run -v $(pwd)/pgdog.toml:/etc/pgdog.toml -p 6432:6432 ghcr.io/pgdog/pgdog:latest
  • 3. Aponte sua aplicação para localhost:6432 no lugar de localhost:5432

Configuração mínima do pgdog.toml: você precisa definir pelo menos a seção [general] com endereço é porta, é a seção [[pools]] com o host do PostgreSQL, banco, usuário é senha. A documentação oficial em pgdog.dev tem exemplos completos para cada modo de pooling.

Para compilar do zero, precisa do Rust instalado (rustup.rs) é rodar cargo build --release dentro do repositório. O binário gerado fica em target/release/pgdog.

Exemplo prático

Imagine uma API Node.js que usa node-postgres é recebe 500 requisições por segundo, cada uma abrindo uma conexão com o banco. Sem pooler, o PostgreSQL vai sofrer com centenas de conexões simultâneas, consumindo muita memória é CPU só para gerenciar conexões.

Com PgDog no meio, a API abre conexão com o pooler (que sempre responde rápido), é o pooler mantém internamente, digamos, 20 conexões reais com o PostgreSQL. Essas 20 conexões atendem as 500 requisições em modo transaction pooling - cada query pega uma conexão livre do pool, executa é devolve.

Para ativar o roteamento de leitura/escrita, você configura no pgdog.toml o primário é as réplicas. PgDog analisa cada query que passa: se for um SELECT simples fora de transação, manda para uma réplica. Se for INSERT, UPDATE, DELETE ou estiver dentro de uma transação, manda para o primário. A aplicação não muda nada.

Comparação com alternativas

O mercado de proxies para PostgreSQL não é novo. As principais alternativas são:

  • PgBouncer: o mais usado, leve é estável, mas com arquitetura single-thread é sem roteamento SQL. Não entende o conteúdo das queries.
  • Pgpool-II: tem roteamento de leitura/escrita é balanceamento, mas é muito mais complexo de configurar é operar. Pode ser um ponto único de falha se não configurado bem.
  • Odyssey: desenvolvido pela Yandex, multithreaded como PgDog, mas com menos recursos de roteamento é comunidade menor.
  • Supavisor: da equipe do Supabase, escrito em Elixir, focado em escala massiva.

PgDog se posiciona entre PgBouncer (simples, mas limitado) é Pgpool-II (poderoso, mas complexo). Se você precisa de pooling mais roteamento sem a complexidade do Pgpool-II, PgDog é um candidato forte - especialmente agora que está recebendo investimento é desenvolvimento ativo.

Pontos positivos é limitações

O que é bom: desempenho alto por conta do Rust é multithreading, roteamento automático de leitura/escrita, configuração mais simples que Pgpool-II, ativo com financiamento é desenvolvimento constante, totalmente open source.

Limitações reais que você vai encontrar: ainda é relativamente novo, então não tem o histórico de estabilidade de anos que o PgBouncer tem. A comunidade ainda é pequena comparada ao PgBouncer, o que significa menos exemplos documentados é menos integrações prontas.

O suporte a prepared statements no modo transaction pooling tem algumas limitações que o PgBouncer também tem: algumas ORMs como ActiveRecord (Rails) ou Hibernate podem precisar de ajustes de configuração. Consulte a documentação antes de migrar uma aplicação crítica.

Casos de uso reais

API com picos de conexão: aplicações web ou mobile que têm muitos usuários simultâneos se beneficiam imediatamente do connection pooling. Com PgDog, você reduz de centenas de conexões ativas no PostgreSQL para dezenas.

Arquitetura com réplicas de leitura: se você já tem ou planeja ter réplicas para distribuir a carga de leitura (relatórios, dashboards, queries pesadas), PgDog faz o roteamento automático sem mudar código da aplicação.

Migração gradual do PgBouncer: equipes que usam PgBouncer é querem mais recursos sem migrar para Pgpool-II podem usar PgDog como caminho intermediário.

Startups com PostgreSQL na AWS/GCP: quem usa RDS ou Cloud SQL com múltiplas réplicas de leitura pode aproveitar o balanceamento automático para reduzir carga no primário sem precisar de configuração complexa no HAProxy.

Dicas é boas práticas

Antes de colocar em produção, teste com uma carga similar à real. Use ferramentas como pgbench ou k6 para simular conexões é queries. Verifique se o comportamento de prepared statements da sua ORM é compatível com o modo de pooling escolhido.

No modo transaction pooling (o mais eficiente), evite usar SET é variáveis de sessão, porque a conexão com o banco pode mudar entre transações. Se a aplicação depende de variáveis de sessão do PostgreSQL, use session pooling no lugar.

Monitore as métricas de conexões no início. PgDog expõe dados sobre conexões ativas, idle, aguardando é tempo de espera. Se o pool estiver sempre lotado (todas as conexões em uso), aumente o tamanho do pool ou investigue queries lentas que estão segurando conexões.

Vale a pena?

Se você usa PostgreSQL com múltiplos clientes simultâneos é ainda não tem um pooler, PgDog é uma ótima opção para experimentar em 2026. A instalação é simples, o desempenho é bom é o roteamento automático de leitura/escrita é um diferencial real.

Se já usa PgBouncer é está satisfeito, não precisa migrar agora. PgBouncer ainda é mais maduro é testado em produção. Mas se você precisa de roteamento de réplicas ou sente os limites do single-thread do PgBouncer, vale testar PgDog em staging é comparar.

O próximo passo é simples: acesse pgdog.dev, leia o guia de início rápido é teste em um ambiente local. Leva menos de 15 minutos para ter rodando com Docker.