Formas de capturar cambios en Postgres

• El artículo analiza varias formas de capturar cambios en una base de datos Postgres.
• Una empresa llamada Sequin sincroniza datos desde APIs de terceros como Salesforce y HubSpot para que los desarrolladores construyan sobre esos datos de API usando su base de datos Postgres.
• Postgres ofrece varias opciones para capturar datos en movimiento, como activar flujos de trabajo basados en cambios en tablas o transmitir datos en tiempo real a otros almacenes de datos, sistemas o servicios.
• El enfoque más simple es usar Listen/Notify, la función de comunicación entre procesos de Postgres. Es una implementación del patrón publish-subscribe, pero tiene limitaciones como semántica de entrega de "como máximo una vez" y un límite de tamaño de carga útil de 8000 bytes.
• Otro método es hacer polling directamente sobre las tablas, lo que requiere que cada tabla tenga una columna updated_at o similar que se actualice cada vez que se modifica una fila. Sin embargo, este método no puede detectar cuándo se eliminan filas y no proporciona diffs.
• Postgres admite replicación por streaming hacia otra base de datos Postgres, y eso puede usarse para capturar cambios de una aplicación. Sin embargo, este método es complejo y puede requerir ajustar postgresql.conf.
• Los cambios también pueden capturarse desde tablas de auditoría que registran las modificaciones. Este enfoque es similar a usar replication slots, pero es más manual.
• También existen los foreign data wrappers (FDWs), una función de Postgres que permite leer y escribir desde fuentes de datos externas. Sin embargo, este método solo se recomienda en situaciones muy específicas.
• En conclusión, la mejor manera de capturar cambios en Postgres depende del caso de uso. Listen/Notify es bueno para capturar eventos no críticos, hacer polling de cambios es una solución intuitiva para casos simples, y la replicación es la mejor opción para una solución robusta. Si la replicación resulta demasiado difícil, las tablas de auditoría pueden ser una buena solución intermedia.

[GN⁺]

Opiniones de Hacker News

• El artículo analiza varias formas de capturar cambios en Postgres, un sistema de bases de datos muy popular.
• Un comentarista recomienda enfáticamente usar triggers y tablas de historial (tablas de auditoría) para capturar cambios, una técnica que se ha usado por más de 30 años.
• El comentarista proporciona un enlace a una guía sobre cómo implementar esta técnica y advierte sobre el uso de bibliotecas de seguimiento de historial en el espacio de la aplicación.
• Otro comentarista comparte una experiencia positiva con el patrón de Temporal Tables, que permite ver el estado de una tabla en un momento específico.
• Otro comentarista sugiere usar una extensión probada llamada pgaudit que genera tablas de auditoría.
• Algunos comentaristas discuten los riesgos potenciales de ciertos métodos, como hacer polling de una columna updated_at.
• Se menciona una biblioteca para usuarios de Elixir y Postgres que escucha cambios en el WAL.
• Varios comentaristas expresan que hace falta innovación en esta área y sugieren que Postgres se beneficiaría de una función que empuje incrementalmente los resultados de las consultas.
• Un comentarista advierte sobre los riesgos de usar replicación para capturar cambios, diciendo que si Postgres deja de consumir los datos, puede seguir almacenando los datos perdidos hasta que el disco se llene.
• El mismo comentarista dice que usa polling, pero recomienda almacenar txid en lugar de updated_at.
• La discusión resalta una parte del mundo de los datos: la necesidad de una solución elegante para empujar incrementalmente los resultados de las consultas.