DBOS Otimiza Escalabilidade do LISTEN/NOTIFY do PostgreSQL com Buffering e Batching

A equipe da DBOS abordou um gargalo histórico do PostgreSQL: o recurso LISTEN/NOTIFY. Embora poderoso para comunicação assíncrona, ele sofria com problemas de escalabilidade devido a um bloqueio global exclusivo. Este lock é acionado no commit de transações que usam NOTIFY, travando a gravação enquanto a transação é finalizada e os dados são sincronizados com o disco. Essa serialização impedia otimizações como o group commit, limitando o throughput a cerca de 2.9 mil escritas por segundo, sem sobrecarregar visivelmente CPU ou I/O.

A solução da DBOS envolveu um truque elegante: tratar as notificações não como fonte de dados, mas como meros 'sinais de despertar'. Eles implementaram um mecanismo de buffering e batching para as chamadas NOTIFY, periodicamente descarregando esses buffers em uma única transação. Isso minimiza a frequência do bloqueio global. Para garantir a resiliência contra falhas que possam impedir a entrega de notificações em buffer, foi adicionado um polling ocasional como fallback. Com isso, o sistema alcança 60 mil escritas por segundo com latência de 15 a 100 milissegundos.

A otimização do LISTEN/NOTIFY pelo DBOS é crucial para arquiteturas que demandam comunicação em tempo real e alta escalabilidade diretamente do PostgreSQL. Agora, o banco de dados pode ser a espinha dorsal de sistemas de streaming de dados, pub/sub e notificações com baixa latência, evitando a necessidade de infraestruturas de mensagens externas mais complexas. Isso reforça a versatilidade do PostgreSQL e se alinha à tendência de extrair o máximo desempenho desse banco de dados, como vimos na cobertura anterior do CEVIU sobre a otimização de pruning em colunas não-particionadas em 14 de julho de 2026, ou a chegada de ferramentas como o PgDog em 11 de julho de 2026 para gerenciar conexões.