PgDog conclui captação e chega a um banco de dados perto de você

• PgDog é um proxy colocado na frente do PostgreSQL que permite escalar o Postgres horizontalmente por meio de pool de conexões, balanceamento de carga e sharding, sem reescrever a aplicação
• A equipe vê o motivo de existirem bancos de dados como Mongo ou Dynamo como sendo o problema de escalabilidade do Postgres e acredita que, se ele pudesse lidar com tabelas de mais de 100 TB e 1 milhão de consultas por segundo, não haveria necessidade de outros bancos de dados
• O PgDog processa mais de 2 milhões de consultas por segundo em produção, fez sharding confirmado de mais de 20 TB e já ultrapassou 1,4 milhão de pulls do Docker no GitHub
• A equipe de três pessoas lidou com problemas de sharding do Postgres em RDS, Aurora e EC2 com base na experiência em aplicações de grande escala sobre Postgres e na expansão de 5x da Instacart em abril de 2020
• Captou US$ 5,5 milhões com Basis Set, YC, Pioneer Fund e outros, e está construindo o PgDog como um produto open source para fazer o Postgres funcionar em qualquer escala

---

Captação e direção do produto

• O desenvolvimento do Postgres começou a partir da visão de que ele é o único banco de dados necessário
• A existência de bancos de dados como Mongo ou Dynamo é vista como resultado do problema de escalabilidade do Postgres
• A equipe acredita que, se o Postgres pudesse lidar corretamente com tabelas de mais de 100 TB e 1 milhão de consultas por segundo, não usaria outro banco de dados
• O PgDog possibilita escala horizontal ao colocar um proxy na frente do Postgres existente
• O PgDog pode ser implantado em qualquer lugar, incluindo on-premises e na conta de nuvem do usuário
• Basta baixar a imagem Docker e mudar o DATABASE_URL para deixar o PgDog assumir o trabalho

Situação atual e contexto de execução

• Estado atual

  • O PgDog está processando mais de 2 milhões de consultas por segundo em dezenas de ambientes de produção
  • Dentro da faixa verificada, o PgDog fez sharding de mais de 20 TB
  • O PgDog é open source e qualquer pessoa pode implantá-lo
  • Já ultrapassou 1,4 milhão de pulls do Docker no GitHub
  • Novas versões saem toda quinta-feira
  • A comunidade no Discord está crescendo, com respostas a perguntas e suporte todos os dias

• Equipe e base de confiança

  • O PgDog é uma pequena startup com uma equipe de três pessoas
  • A equipe é formada por engenheiro de infraestrutura, engenheiro de aplicações e um generalista
  • A equipe criava aplicações baseadas em Postgres e as fazia operar em grande escala antes mesmo de o Postgres ganhar ampla atenção
  • Na Instacart, acumulou experiência operando Postgres durante a expansão de 5x da empresa em abril de 2020
  • Na época, o maior desafio era fazer o Postgres lidar com centenas de milhares de pedidos de entrega de supermercado por minuto
  • Eles fizeram sharding do Postgres em RDS, Aurora e EC2, resolvendo problemas reais com princípios básicos e muito código
  • Essa mesma tecnologia agora é oferecida como produto open source

• Forma de implantação e financiamento

  • O desenvolvimento do PgDog não é um pivot; o único objetivo continua sendo escalar o Postgres
  • O PgDog foi feito para rodar na nuvem do usuário, em rack de colocation, on-premises ou no notebook
  • O PgDog funciona onde for necessário, sem dependências nem custos serverless ocultos
  • Se houver CPU disponível, o código multithread do PgDog usa toda a capacidade
  • A equipe acredita que a adoção do Postgres continuará crescendo
  • Captou US$ 5,5 milhões de Basis Set, YC, Pioneer Fund e outros investidores, garantindo runway para vários anos
  • O objetivo é fazer o Postgres funcionar corretamente para todos e em qualquer escala

• Enterprise edition

  • A Enterprise edition do PgDog está sendo desenvolvida para rodar com mais facilidade na AWS
  • A Enterprise edition oferece suporte da equipe com base em SLA

[GN⁺]

Comentários do Hacker News

• Dizem que o motivo de existirem bancos de dados como Mongo ou Dynamo são os problemas de escalabilidade do Postgres, mas, depois de usar Postgres em vários lugares, o problema nº 1 sempre foi alta disponibilidade, não escalabilidade
  Com um único cluster Postgres, processamos facilmente 100 mil transações por minuto, mas quando o nó principal morria, alguém precisava ser acionado, fazer o failover manual para o nó de standby e depois também substituir manualmente esse standby
  As ferramentas manuais eram muito complicadas, mas pelo menos funcionavam; as soluções automatizadas nem chegavam perto
  Por falta de uma boa história de HA, acabei evitando ao máximo Postgres autogerenciado

  • Nós também oferecemos suporte a HA: https://docs.pgdog.dev/features/load-balancer/
    Um balanceador de carga com health checks e failover já vem funcionando por padrão, e agora já foi suficientemente testado em produção para valer a pena dar uma olhada
  • O Patroni 1.0 saiu em 2016, então isso foi há quase 10 anos
    https://github.com/patroni/patroni
  • Fico curioso se você já usou cnpg
    Para o meu caso de uso, funcionou muito bem
  • Hoje em dia o Patroni resolve muito bem essa área
  • Também fico curioso se você já olhou algo como CloudNativePG: https://cloudnative-pg.io/

• Se no “Why Us” está escrito “Operamos Postgres na Instacart e, quando a empresa cresceu 5x em abril de 2020, o maior problema foi fazer o Postgres processar centenas de milhares de pedidos de entrega de supermercado por minuto”, então acho difícil haver um por que nós melhor do que esse

  • 100 mil pedidos por minuto é muito?
    Parece algo que uma única instância de Postgres conseguiria processar sem problemas
  • Fico curioso por que mudaram a referência para por minuto
    SSDs corporativos modernos e de alta qualidade conseguem lidar com algo em torno de 35 mil fsync reais por segundo
  • Sempre achei a Instacart extremamente lenta e com muita latência
    Claro, não sei se isso era por causa do Postgres ou por outras falhas de arquitetura

• Estou tentando entender o básico, mas hoje tenho um DB de 4 TB em um único servidor grande
  Se eu usar uma ferramenta de proxy como o PGDog, isso vira uma estrutura com 8 servidores menores, cada um cuidando de cerca de 500 GB, e 1 servidor intermediário de porte médio para o proxy?
  No projeto atual, há muito tráfego de escrita vindo de vários serviços, e a aplicação web lê daqui
  Estamos chegando perto do ponto em que indexação, otimização de consultas, cache e upgrade de servidor já não ajudam mais
  Também estamos avaliando mover a maior parte dos dados estáticos para o ClickHouse para reduzir o tamanho do DB, mas gostaria de ouvir se PgDog ou outro tipo de sharding seria útil para esse caso

  • “8 servidores menores, cada um cuidando de cerca de 500 GB, e 1 servidor intermediário de porte médio para o proxy” é exatamente essa a estrutura
    Seria ótimo se você entrasse em contato ([e-mail])
    Posso ajudar ou, no mínimo, dizer o que está funcionando e o que não está hoje para que você entenda as opções
  • Isso é o conceito de sharding
    Se você ler a documentação do pgdog, vai ver que é preciso informar para qual servidor de shard cada requisição deve ser roteada; não é algo que simplesmente funciona por mágica
    Ainda assim, isso tem valor porque reutiliza conexões especialmente caras no Postgres
    Como não é mágica, você precisa entender o que está acontecendo por baixo dos panos e, por exemplo, não há transações entre shards
    Sharding é difícil se você se preocupa com consistência de dados, então eu primeiro veria se a aplicação pode se beneficiar de réplicas de leitura
    Cada réplica tem uma cópia completa dos dados e as escritas vão apenas para o master, e você precisa decidir por conta própria quais transações podem rodar em réplicas que ficam um pouco atrás do quase tempo real
    Por exemplo, leituras para montar uma página web costumam ser seguras em réplicas, mas leitura-modificação-escrita não é

• Fico curioso para saber como isso ajudaria com upgrades de versão major, a maior causa de downtime no Postgres
  O pooler é excelente para failover e balanceamento de carga, mas por causa de upgrades ainda é preciso um downtime recorrente de uns 10 a 20 minutos, uma ou duas vezes por ano
  A replicação lógica da versão antiga para a nova pode ajudar, mas ainda parece necessário transferir tudo para o novo cluster sem escritas parciais nem estados estranhos
  Queria saber se alguém tem experiência com isso

  • Nós usamos replicação lógica e pausa/troca no pgbouncer para que as escritas não falhem, apenas fiquem pausadas por cerca de 5 segundos
    O banco tem cerca de 1 a 1,5 TB, mas o volume de mudanças e o número de queries por segundo não são absurdamente altos
    É basicamente o método descrito aqui: https://www.pgedge.com/blog/always-online-or-bust-zero-downt...
  • Normalmente isso é resolvido com replicação lógica
    Se você tiver infraestrutura como código, cria um novo cluster com a mesma configuração e apenas a versão major diferente, importa o schema, começa a copiar os dados a partir de uma réplica de leitura da versão antiga, para de aceitar escritas na versão antiga (início do downtime), sincroniza os números das sequências e aponta o serviço para o novo cluster (fim do downtime)
    Se usar algo como CloudNativePG, parte desse processo é automatizada com ferramentas de CLI e sintaxe declarativa
    Caso contrário, você mesmo precisa investir tempo para entender tudo
    Pode parecer complexo, mas depois de praticar em um banco de staging, se funcionar bem, é só repetir o mesmo procedimento em produção
    Além disso, parece que o Postgres 19 terá um patch para replicação lógica pontual de sequências: https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...
  • A replicação lógica resolve isso
    Se você fizer a rotação dos clusters em sequência, o downtime fica bem pequeno, algo em torno de 60 segundos
  • É estranho que o PostgreSQL ainda não tenha uma implementação open source genérica e decente de multi-master
    A esta altura, fico na dúvida se ainda vou ver isso algum dia
  • Vindo do MySQL, isso é um grande retrocesso e faz o Postgres parecer coisa dos anos 80
    Ainda me pergunto por que isso nunca é tratado como prioridade absoluta

• Parabéns pelo investimento, Lev
  Estamos usando o PgDog aqui com satisfação
  Gosto bastante de um recurso do proxy que lida com configurações de conexão diferentes por conexão, por exemplo statement_timeout
  Quando investiguei o RDS Proxy no passado, ele não suportava isso, e acho que o pgbouncer também não, então teria sido necessário mudar bastante a aplicação
  No PgDog, isso simplesmente funciona de forma transparente

• Fico curioso se isso é comparável ao multigres da Supabase, que acabou de ser anunciado

• Vejo que existe uma Enterprise Edition; queria entender com clareza quais recursos não são open source
  Também queria saber se devemos esperar que os novos recursos adicionados venham sob licença EE para dar retorno aos investidores de VC

  • Há dois recursos grandes
    O primeiro é um control plane para gerenciar implantações multinó, oferecendo uma experiência “pronta para usar” que facilita implantar e operar o PgDog
    O segundo é qualidade de serviço (QoS), que bloqueia automaticamente queries problemáticas para que não derrubem o banco de dados
    Por fim, também é possível obter suporte com SLA garantido até P0
    Os novos recursos se dividem em duas categorias
    Sharding e operação de Postgres em grande escala serão sempre open source, enquanto gerenciamento de infraestrutura e recursos que tornam o PgDog fácil de operar em larga escala serão enterprise

• É bom ver surgirem PgDog, Neki e multigres
  Isso mesmo é o problema central do Postgres, e a ausência de index hints também é um problema, então estou ansioso pelo Postgres 19

  • Não podemos esquecer do original, o PgBouncer
    A configuração é difícil, mas hoje em dia ficou mais fácil montar tudo com ajuda de IA
  • A extensão pg_hint_plan não está no core, mas é bastante competente quando você precisa sobrescrever o planner

• “Shardamos mais de 20 TB, pelo que sabemos” provavelmente é um erro de digitação
  20 TB não é tão grande assim
  Imagino que tenham shardado bem mais do que isso

  • Se você acha que 20 TB “não é tão grande assim”, eu queria saber com que tamanho de banco você trabalha
  • Se o conjunto de trabalho for de 20 TB, então é bem grande
    A proporção entre dados quentes e frios varia de banco para banco, então sem mais informações não dá para comparar
    Uma métrica melhor talvez seja IOPS
    O RDS tem um IOPS máximo bem baixo, a menos que você gaste muito mais com IOPS provisionado ou use Aurora
  • Sim
    Como comparação, quase 10 anos atrás, na Segment, operávamos uma única instância Aurora PostgreSQL com cerca de 50 TB de dados, usada para indexar dados potencialmente identificáveis dentro de um corpus de arquivos muito maior armazenado no S3
  • Para a maioria dos casos de uso, 20 TB é definitivamente enorme

• O PgDog é legal
  Sinceramente eu não preciso dele, mas estava fazendo trilha no mato sem nada para ouvir, acabei tropeçando no podcast Postgres FM, achei interessante e agora estou usando no meu Kubernetes on-premises
  https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb