Maneiras de capturar mudanças no Postgres

• O artigo discute várias maneiras de capturar mudanças no banco de dados Postgres.
• Uma empresa chamada Sequin sincroniza dados de APIs de terceiros, como Salesforce e HubSpot, para que desenvolvedores possam usar seus bancos de dados Postgres para estruturar dados de API.
• O Postgres oferece várias opções para capturar dados em movimento, como acionar fluxos de trabalho com base em mudanças em tabelas ou transmitir dados em tempo real para outros armazenamentos de dados, sistemas ou serviços.
• A abordagem mais simples é usar o Listen/Notify, recurso de comunicação entre processos do Postgres. Trata-se de uma implementação do padrão publish-subscribe, mas com limitações como semântica de entrega "no máximo uma vez" e limite de 8000 bytes no tamanho do payload.
• Outro método é fazer polling diretamente nas tabelas, o que exige que cada tabela tenha uma coluna updated_at ou algo semelhante, atualizada sempre que uma linha for modificada. No entanto, esse método não consegue detectar quando linhas são excluídas e não fornece diffs.
• O Postgres oferece suporte à replicação por streaming para outros bancos Postgres, e isso pode ser usado para capturar mudanças da aplicação. Porém, esse método é complexo e pode exigir ajustes no postgresql.conf.
• As mudanças também podem ser capturadas em tabelas de auditoria que registram as alterações. Essa abordagem é semelhante ao uso de replication slots, mas é mais manual.
• Também existem os foreign data wrappers (FDWs), um recurso do Postgres que permite ler e escrever em fontes de dados externas. No entanto, esse método só é recomendado em situações muito específicas.
• Em conclusão, a melhor forma de capturar mudanças no Postgres depende do caso de uso. Listen/Notify é bom para capturar eventos não críticos, fazer polling de mudanças é uma solução intuitiva para casos de uso simples, e a replicação é a melhor escolha para uma solução robusta. Se a replicação for difícil demais, tabelas de auditoria podem ser uma boa solução intermediária.

[GN⁺]

Comentários do Hacker News

• O artigo discute várias maneiras de capturar mudanças no Postgres, um sistema de banco de dados popular.
• Um comentarista recomenda fortemente capturar mudanças usando triggers e tabelas de histórico (tabelas de auditoria), uma técnica usada há mais de 30 anos.
• O comentarista fornece um link para um guia sobre como implementar essa técnica e alerta sobre o uso de bibliotecas de rastreamento de histórico no espaço da aplicação.
• Outro comentarista compartilha uma experiência positiva com o padrão Temporal Tables, que permite ver o estado de uma tabela em um momento específico.
• Outro comentarista sugere usar uma extensão comprovada chamada "pgaudit", que cria tabelas de auditoria.
• Alguns comentaristas discutem os riscos potenciais de certos métodos, como fazer polling de uma coluna updated_at.
• Há menção a uma biblioteca para usuários de Elixir & Postgres que escuta mudanças no WAL.
• Alguns comentaristas expressam que há necessidade de inovação nessa área e sugerem que o Postgres poderia se beneficiar de um recurso que faça push incremental dos resultados de consultas.
• Um comentarista alerta sobre os riscos de capturar mudanças usando replicação, dizendo que, se o Postgres parar de consumir os dados, os dados perdidos podem ser armazenados até o disco encher.
• O mesmo comentarista sugere usar polling, mas armazenando txid em vez de updated_at.
• A discussão destaca uma parte do mundo de dados: a necessidade de uma solução elegante para fazer push incremental dos resultados de consultas.