DBOS chega a 1 milhão de durable workflows por segundo no Postgres com sharding via PgDog

A DBOS mediu durable workflows no-op (sem steps) em Postgres sharded com PgDog. O resultado escalou de forma linear: 20 mil workflows por segundo com um servidor RDS db.m7i.4xlarge (16 cores, 64 GB de RAM) até 1 milhão por segundo com 50 shards. Foram 48 processos worker por shard, 2.400 no total, todos conectados a um roteador PgDog no próprio host. Os workflows entram numa única fila durável, com shard key aleatória uniforme.

Para a escala ser linear, cada operação de um workflow precisa cair em um único shard. Por isso a DBOS adicionou a coluna shard_key à tabela workflow_status e às dependentes, como workflow_steps. O dequeue também passou a ser por shard: cada processo percorre os shards um de cada vez. O problema apareceu entre 8 e 16 shards (cerca de 200 mil workflows/s). Qualquer perturbação, como um VACUUM grande, derrubava o cluster inteiro sem recuperação. A causa era um loop de feedback no dequeue com FOR UPDATE SKIP LOCKED: dequeues mais lentos atraem mais processos concorrentes, que geram mais contenção de lock, e a query precisa varrer mais linhas bloqueadas até achar uma livre. A correção foram advisory locks do Postgres, com poucos "dequeue locks" por shard. Quem não consegue o lock não espera e passa para o próximo shard.

Em 1 de maio de 2026, o CEVIU noticiou "Escala da Execução de Workflows no Postgres": um único servidor sustentava 144 mil escritas brutas e 43 mil workflows duráveis por segundo, com gargalos em WAL flushing e contenção de lock de tabela. Agora o teste usa 20 mil workflows/s por shard como teto sustentável e vai a 1 milhão por segundo com sharding. O gargalo relevante também mudou: em escala horizontal, o problema foi a contenção no dequeue, não o WAL de um nó. Os números dos dois testes não são diretamente comparáveis, já que o material não detalha se a configuração é a mesma.

Para quem opera filas ou orquestração sobre Postgres, a leitura é que sharding sozinho não basta. Se o seu worker faz polling com SKIP LOCKED em muitos processos, vale observar a latência do dequeue por shard e limitar a concorrência. Um VACUUM pesado pode virar incidente global sem esse freio. Em custo, o teste mostra o preço da escala: 50 instâncias RDS de grande porte para 1 milhão por segundo, num benchmark de workflows no-op.