PgDog - uma ferramenta para fazer sharding do Postgres sem extensões adicionais

• Pooler de transações e gerenciador de replicação lógica para PostgreSQL desenvolvido em Rust, oferecendo escalabilidade horizontal e automação de sharding
• Permite fazer sharding de bancos de dados PostgreSQL com facilidade sem extensões, sendo otimizado para gerenciar centenas de bancos de dados e centenas de milhares de conexões
• Atua como um balanceador de carga de banco de dados na camada de aplicação (OSI 7), com roteamento automático de SELECT para réplicas e das demais consultas para o primário
• Assim como o PgBouncer, oferece pooling de transações/sessões, mas também faz parsing das consultas para roteamento automático aos shards e até a fusão dos resultados
• Usando COPY e replicação lógica, pode distribuir dados automaticamente entre shards ou fazer sharding de um banco existente sem downtime
• A configuração pode ser definida de forma simples em arquivos TOML, com reconfiguração em tempo de execução
• Diferentemente do Citus, que usa extensões do Postgres, é um proxy externo ao banco, então também pode ser usado em RDS, Cloud SQL etc.

---

Introdução ao projeto e principais valores

• PgDog é uma solução open source para PostgreSQL que oferece suporte amplo à expansão horizontal, com sharding simplificado, replicação lógica, pooling de transações e balanceamento L7
• Desenvolvido na linguagem Rust, garante alto desempenho e segurança
• Sem necessidade de instalar extensões, o PgDog permite implementar sharding, distribuição de dados, recuperação de falhas e balanceamento de carga flexível com a implantação de um único proxy
• Ao contrário de produtos concorrentes (ex.: PgBouncer, PgCat), seu diferencial é oferecer também sharding automático e replicação lógica, além de alterações de configuração em produção e monitoramento em tempo real

Principais recursos

Balanceamento de carga (Load Balancer)

• O PgDog é um proxy em nível de aplicação da camada 7 do OSI, que distribui consultas entre vários nós primários e réplicas do PostgreSQL para evitar falhas e sobrecarga
• Oferece diversas estratégias de distribuição, como round-robin, aleatória e menor número de conexões
• Identifica o tipo de consulta para encaminhar automaticamente SELECT para réplicas e as demais consultas de escrita para o nó primário
• Executa health checks e failover automático em caso de falhas, garantindo disponibilidade mesmo diante de erros de rede ou falhas de hardware

Pooling de transações

• Assim como o PgBouncer, o PgDog oferece pooling de transações e sessões para gerenciar recursos de conexão com eficiência, permitindo atender centenas de milhares de clientes com poucas conexões de backend

Sharding

• Faz parsing direto da sintaxe das consultas para extrair a chave de shard e aplicar o algoritmo de roteamento ideal
• Também suporta consultas cross-shard entre bancos de dados multi-shard, consolidando os resultados em memória e entregando-os ao cliente de forma transparente
• Ao executar o comando COPY, suporta distribuição de dados em múltiplos shards via parsing de CSV, o que é conveniente para cargas de grande volume
• Com base no protocolo de replicação lógica do PostgreSQL, permite sincronização em segundo plano sem downtime, além da adição e expansão de shards em tempo real durante a operação

Monitoramento

• Suporta tanto um banco de administração no estilo PgBouncer quanto um endpoint OpenMetrics
• Fornece exemplos de monitoramento externo e dashboards com Datadog e outras ferramentas

Configuração e runtime

• Principais ambientes: Kubernetes (com chart Helm), Docker e ambiente local (build em Rust), permitindo implantação e testes com facilidade
• Em geral, basta escrever 2 arquivos de configuração (pgdog.toml, users.toml) para concluir a configuração mínima de sharding e de operação baseada em usuários
• A maioria dos valores de configuração pode ser modificada em tempo real e aplicada dinamicamente sem reiniciar o processo

Desempenho e licença

• O PgDog é um proxy de rede assíncrono de alto desempenho baseado em Rust e Tokio, com foco em minimizar a movimentação de dados e conter a degradação de desempenho
• Os resultados de benchmark são fornecidos na documentação oficial para servir como referência de desempenho
• Adota a licença open source AGPL v3, totalmente aberta para uso interno corporativo e customizações privadas
• No entanto, empresas que oferecem serviços em nuvem pública têm a obrigação de compartilhar as alterações feitas no código

Status do projeto e contribuição

• Atualmente o projeto está em estágio inicial, sendo recomendada sua adoção por early adopters, enquanto a estabilidade de cada recurso segue sendo aprimorada continuamente
• Testes por funcionalidade e benchmarks também continuam sendo realizados
• Contribuições da comunidade open source são bem-vindas; veja mais detalhes nas Contribution Guidelines

Conclusão

• O PgDog oferece uma excelente solução para equipes de desenvolvimento e empresas que precisam de escalabilidade horizontal, alta disponibilidade e sharding automático do PostgreSQL em ambientes de produção
• Sua grande vantagem é poder ser aplicado rapidamente e customizado sem necessidade de extensões adicionais ou de uma infraestrutura complexa

[GN⁺]

Comentários no Hacker News

• Ao cumprimentar Lev, explicou a situação atual de comparar o PgDog com uma solução própria para shardear um banco de dados Postgres de 40 TB, mencionando que precisa de algo que funcione como um Vitess for PostgreSQL; enfatizou que, além da função de scatter-gather, também são necessários gerenciamento de configuração baseado em algo como etcd, divisão de shards e transações best-effort para aplicar mudanças de esquema em todos os shards; perguntou sobre a experiência com reescrita de consultas usando pg_query.rs, compartilhando que achou difícil por causa da imutabilidade dos tipos de AST e da falta de deep clone, e contou que no fim está usando o crate sqlparser com suporte ao padrão Visitor, além de desenvolver como projeto paralelo uma ferramenta de mudança de esquema online para PG baseada em shadow tables e replicação lógica

  • Disse que ficou feliz com a proposta de colaboração e compartilhou um contato; explicou que o gerenciamento de configuração já pode ser resolvido com K8s ou várias ferramentas de CD e que é possível sincronizar o reload da configuração do PgDog; mencionou que mudanças de esquema em todos os shards com transações best-effort já estão funcionando, que mudanças de esquema idempotentes são o ideal, mas que two-phase commit também está sendo considerado em caso de falha; deu como exemplo que a divisão de shards pode ser feita com replicação lógica, citando experiência com mais de 10 TB na Instacart, e compartilhou o procedimento de abrir slots de replicação, restaurar em N instâncias, apagar dados com número de shard incompatível e ressincronizar por replicação lógica; falou também da ideia de usar a replicação lógica do Pg 17 em streaming replicas para divisão paralela e de um método para fazer COPY dos dados diretamente com foreign tables; acrescentou que pg_query.rs agora parece funcionar de forma mutável e que recentemente tem usado ativamente para reescrita e geração de consultas, destacando como grande vantagem o fato de ser 100% baseado no parser do Postgres, e que a funcionalidade de "deparse" está espalhada por toda parte, o que amplia bastante as possibilidades para trabalhos complexos

• Perguntou se, caso existisse um Vitess for Postgres, o Yugabyte não estaria cumprindo esse papel

• Disse que, olhando só para as funções centrais, parece pequeno, mas considera uma enorme vantagem do PgDog separar leituras para read replicas e escritas para a primária sem exigir mudanças no código; como muitos apps não oferecem suporte direto à separação R/W, comentou que fazer isso no nível do proxy já trouxe grandes ganhos de velocidade no passado e elogiou o projeto

  • Informaram que essa função já pode ser usada no pgcat e compartilharam o link do pgcat

  • Compartilhou que na Instacart faziam separação R/W com Makara, mas que era bem trabalhoso implementar a mesma coisa repetidamente em vários ambientes de linguagem, como Python e Go

• Elogiou o projeto e disse ficar um pouco desconfortável com sharding totalmente automatizado; explicou que, em geral, o sharding acontece nos limites de tenancy e que prefere haver fricção ao cruzar esse limite; opinou que joins entre shards são diferentes de joins dentro do shard em desempenho, memória e CPU, então isso deveria ficar mais explícito; ainda assim, afirmou não duvidar do projeto em si e acreditar que haverá muitos casos de uso

  • Perguntou por que querer fricção de propósito e acrescentou que os problemas de desempenho de joins entre shards são em sua maioria bem compreendidos e podem ser acompanhados com métricas em tempo real; no fim, disse que os dois métodos são necessários e que a alternativa de fazer joins no código da aplicação não é muito desejável

• Comentou que está de olho no PgDog e o considera muito impressionante, parabenizando pelo lançamento e dizendo esperar que continue evoluindo

  • Respondeu que a jornada de 15 anos está apenas começando

• Opinou que o principal atrativo é processar consultas distribuídas mantendo transparência e compatibilidade na camada de rede; disse que as limitações atuais na documentação são naturais e espera que alguns trade-offs sejam inevitáveis; ficou curioso para saber como isso será resolvido e propôs participar se houver mais discussões

  • Convidou a participar da comunidade no Discord e compartilhou o link de convite

• Disse que a maior dificuldade em uma solução como o PgDog é tratar corretamente até o último 1% das consultas complexas shardadas (ou detectar consultas anômalas), ou então garantir completamente isolamento e consistência

• Comentou que, assim que viu a documentação, a primeira coisa que foi verificar foi o suporte a Unique Index, mas achou uma pena que ainda não seja suportado por exigir reescrita de consultas e um motor de execução separado; ainda assim, disse ver bastante potencial e estar animado

  • Responderam que, como pequena compensação, a geração de chaves primárias únicas em todos os shards já é suportada e compartilharam a documentação relacionada; acrescentaram que implementar índices únicos cross-shard é caro porque exigiria verificar todas as consultas, e deixaram a ideia em aberto

• Enfatizou que é o projeto de Postgres mais interessante que viu em anos; opinou que os benchmarks apresentados parecem cobrir apenas connection pooling básico e disse ter curiosidade sobre os resultados quando entram em cena parsing de consultas ou joins entre shards

  • Explicou que o parser de consultas é armazenado em cache, então, ao usar prepared queries ou placeholders, o custo adicional é praticamente nulo, limitado a lock e consulta de hash; no caso de joins entre shards, previu que o custo de processamento pode aumentar quando os filtros não são ideais e que talvez seja necessário paginar em disco quando o conjunto de resultados for grande; disse que o foco inicial é OLTP e tentar fazer o máximo possível de pushdown dos joins, mas prevê que a demanda por joins entre shards deve crescer em breve

• Avaliou como uma inovação indispensável para a escalabilidade do Postgres e parabenizou pelo lançamento

• Disse que o projeto parece excelente e parabenizou pelo lançamento

  • Enfatizou que é o resultado de anos de esforço