Toutes les façons de capturer les changements dans Postgres

• L’article examine les différentes façons de capturer les changements dans la base de données Postgres.
• Une entreprise appelée Sequin synchronise des données depuis des API tierces comme Salesforce et HubSpot afin que les développeurs puissent construire des flux de données d’API à l’aide de leur base de données Postgres.
• Postgres offre plusieurs options pour capturer les données en mouvement, comme déclencher des workflows en fonction des changements dans les tables, ou diffuser des données en temps réel vers d’autres stockages de données, systèmes ou services.
• L’approche la plus simple consiste à utiliser Listen/Notify, la fonctionnalité de communication inter-processus de Postgres. Il s’agit d’une implémentation du modèle publish-subscribe, mais avec des limites telles qu’une sémantique de livraison « au plus une fois » et une taille de payload limitée à 8 000 octets.
• Une autre méthode consiste à interroger directement les tables, ce qui suppose que chaque table dispose d’une colonne updated_at ou équivalente, mise à jour à chaque modification d’une ligne. Cependant, cette méthode ne permet pas de détecter la suppression de lignes et ne fournit pas de diff.
• Postgres prend en charge la réplication en flux vers d’autres bases de données Postgres, ce qui peut être utilisé pour capturer les changements d’une application. Cependant, cette méthode est complexe et peut nécessiter d’ajuster postgresql.conf.
• Les changements peuvent aussi être capturés à partir de tables d’audit qui enregistrent les modifications. Cette approche est similaire à l’utilisation de slots de réplication, mais elle est plus manuelle.
• Il existe aussi les foreign data wrappers (FDW), une fonctionnalité de Postgres qui permet de lire et d’écrire vers des sources de données externes. Cependant, cette méthode n’est recommandée que dans des cas très spécifiques.
• En conclusion, la meilleure façon de capturer les changements dans Postgres dépend du cas d’usage. Listen/Notify est bien adapté à la capture d’événements non critiques, le polling des changements est une solution intuitive pour des cas d’usage simples, et la réplication est le meilleur choix pour une solution robuste. Si la réplication est trop difficile à mettre en place, les tables d’audit peuvent constituer une bonne solution intermédiaire.

[GN⁺]

Avis Hacker News

• L’article examine différentes manières de capturer les changements dans Postgres, un système de base de données populaire.
• Un commentateur recommande vivement d’utiliser des triggers et des tables d’historique (tables d’audit), une technique employée depuis plus de 30 ans.
• Le commentateur fournit un lien vers un guide expliquant comment mettre en œuvre cette technique et met en garde contre l’usage de bibliothèques de suivi d’historique côté application.
• Un autre commentateur partage une expérience positive avec le modèle Temporal Tables, qui permet de voir l’état d’une table à un moment précis.
• Un autre commentateur suggère d’utiliser une extension éprouvée appelée pgaudit, qui crée des tables d’audit.
• Certains commentateurs discutent des risques potentiels de certaines méthodes, comme le polling d’une colonne updated_at.
• Il est fait mention d’une bibliothèque pour les utilisateurs d’Elixir & Postgres permettant d’écouter les changements du WAL.
• Quelques commentateurs estiment qu’une innovation est nécessaire dans ce domaine et suggèrent que Postgres gagnerait à pouvoir pousser progressivement les résultats des requêtes.
• Un commentateur met en garde contre les risques liés à l’utilisation de la réplication pour capturer les changements, expliquant que si Postgres cesse de consommer les données, celles manquées peuvent être conservées jusqu’à ce que le disque soit plein.
• Le même commentateur dit utiliser le polling, mais recommande d’enregistrer le txid plutôt que updated_at.
• La discussion met en lumière un aspect du monde de la donnée : le besoin d’une solution élégante pour pousser progressivement les résultats des requêtes.