Egres, banco de dados open-source compatível com o protocolo do Postgres, mira cargas pesadas e multi-tenant

O Egres não é fork nem port do Postgres. Segundo o autor, Manish Jain (fundador da Dgraph Labs, autor do Badger e ex-Uber e Google), o projeto só reaproveita a libpg_query. Ele fala o protocolo do Postgres, então psql, drivers e ORMs conectam sem mudança. O código é aberto sob Apache 2.0 e escrito em Zig, escolha ligada à medição por consulta: o controle explícito de cada alocação permite rejeitar um pedido de memória com erro, em vez de derrubar o processo.

A base técnica é um processo único com o sistema de corrotinas zfiber, que cria uma thread por core lógico e mede ticks de CPU por fiber. O armazenamento usa o zdb, uma floresta de LSM trees com compressão de blocos, checksums, MVCC e coleta de lixo. O I/O é direto, com cache S3-FIFO e prioridades de disco (P0 para consultas, P1 e P2 para compactações). A memória passa por um governor que redimensiona o cache a cada 100 ms. No benchmark de 600 milhões de linhas (580 GiB) contra o Postgres 18, numa máquina Ryzen 5950X de 16 cores com 64 GiB por servidor, o Egres teve p50 menor nas quatro consultas, de 2,9x a 226x. As caudas ficaram mistas: na consulta customer, o Postgres foi 33% mais rápido no p95 e p99.

Há limites claros. Esta versão roda em nó único, o código multi-nó ainda não está habilitado, as consultas são só de igualdade e sem joins, e a memória é rastreada apenas no total do processo. A imposição de limites no meio da consulta fica para versões futuras.

Para quem opera Postgres com muitos índices, terabytes em disco ou milhares de tenants num nó, a proposta mira dores reais: VACUUM, bloat e falta de contabilidade de custo por consulta. Leitura editorial: sem joins e com nó único, o Egres ainda é um projeto para acompanhar, não para migrar. Os números também vêm do próprio autor, então vale reproduzir o benchmark com a sua carga antes de tirar conclusões.