Le node Postgres Trigger dans n8n : déclencher un workflow en temps réel depuis une base PostgreSQL

Une ligne insérée dans une table « leads » doit lancer une qualification par IA. Un nouveau document déposé dans la table de votre base documentaire doit relancer l'indexation RAG. Une réponse d'audit enregistrée doit immédiatement mettre à jour un tableau de suivi. Dans tous ces cas, la source de l'événement est une base PostgreSQL que vous contrôlez entièrement — et pourtant, le réflexe le plus répandu reste d'interroger la table toutes les cinq minutes avec un Schedule Trigger. Le node Postgres Trigger de n8n élimine ce détour : il branche le workflow directement sur le mécanisme LISTEN/NOTIFY natif de PostgreSQL, sans polling, sans webhook applicatif à construire à la main.

Pourquoi le polling n'est pas la bonne réponse ici

Pour une API tierce que vous ne maîtrisez pas, le polling reste parfois la seule option disponible — notre guide sur l'automatisation sans webhook par polling intelligent détaille comment le construire proprement dans ce cas. Mais quand la source est une base PostgreSQL que vous administrez vous-même, imposer un cycle d'interrogation périodique revient à renoncer volontairement à une capacité que la base offre nativement. La littérature sur les architectures événementielles documente précisément cet écart : l'article de synthèse d'Eugster, Felber, Guerraoui et Kermarrec, « The Many Faces of Publish/Subscribe », publié dans ACM Computing Surveys en 2003, formalise pourquoi un modèle de notification poussée (publish/subscribe) découple mieux producteurs et consommateurs d'événements qu'une interrogation périodique, tout en réduisant la latence de bout en bout et la charge inutile sur la source. LISTEN/NOTIFY est l'implémentation native de ce modèle dans PostgreSQL, et le node Postgres Trigger n'est jamais qu'une manière de le brancher sur un workflow n8n.

Comment fonctionne le node techniquement

Contrairement au node Postgres classique (voir notre guide sur les requêtes SQL avec le node Postgres) qui exécute des requêtes à la demande, le Postgres Trigger reste connecté en permanence et attend. Concrètement, à l'activation du workflow, n8n crée automatiquement deux objets côté base : un trigger sur la table surveillée et une procédure associée que ce trigger appelle. Cette procédure exécute un NOTIFY sur un canal dédié à chaque opération concernée, et le node n8n, resté en écoute (LISTEN) sur ce même canal via une connexion Postgres dédiée, reçoit l'événement et démarre l'exécution du workflow — en général en quelques millisecondes.

Le point important à retenir : le trigger et la procédure n'existent que tant que le workflow est actif. Désactiver le workflow les supprime automatiquement ; les réactiver les recrée. C'est pratique pour ne rien laisser traîner en base, mais cela signifie aussi qu'aucun événement survenu pendant une désactivation n'est rattrapé après coup — voir la FAQ pour la parade.

Les deux modes de configuration

Listen and Create Trigger Rule

C'est le mode par défaut, pensé pour le cas courant : vous choisissez une table et une ou plusieurs opérations à surveiller (INSERT, UPDATE, DELETE), et n8n génère lui-même tout le SQL nécessaire — trigger et procédure inclus. Aucune ligne de SQL à écrire de votre côté. C'est le mode adapté à la grande majorité des cas d'usage : « déclenche le workflow à chaque nouvelle ligne dans documents », par exemple.

Listen to Channel

Ce second mode s'adresse aux besoins plus spécifiques : vous fournissez directement le nom d'un canal NOTIFY que vos propres triggers ou fonctions PostgreSQL alimentent. C'est le mode à privilégier dès que la logique de déclenchement dépasse « une opération sur une table » — combiner plusieurs tables, ajouter une condition métier dans la procédure avant de notifier, ou agréger plusieurs écritures en une seule notification. Il demande d'écrire le trigger PostgreSQL vous-même, mais offre un contrôle total sur ce qui déclenche réellement le workflow.

Les permissions PostgreSQL à vérifier avant de promettre quoi que ce soit

C'est le point qui casse le plus souvent une démonstration en direct : pour que n8n puisse créer le trigger et la procédure au moment de l'activation, l'utilisateur du credential doit disposer du privilège TRIGGER sur la table (ou en être propriétaire), ainsi que du privilège CREATE sur le schéma cible. Sur une instance Postgres self-hosted que vous administrez — celle de notre guide de configuration PostgreSQL pour n8n par exemple — ce n'est jamais un problème : le rôle applicatif est généralement propriétaire de ses propres tables. Sur une base managée, en revanche, vérifiez en amont : le rôle postgres fourni par défaut sur un projet Supabase dispose typiquement des droits nécessaires, mais certaines offres cloud restreignent volontairement la création de triggers pour des raisons de gouvernance. Un test d'activation sur un environnement de non-production évite la mauvaise surprise en production.

Cas d'usage concret : réindexer un pipeline RAG sans cron

Un pipeline RAG classique guette les nouveaux documents avec un Schedule Trigger qui interroge périodiquement la source — voir notre guide sur la mise à jour d'un index RAG avec n8n. Si vos documents transitent par une table Postgres intermédiaire (un import ERP, une extraction PDF déposée en base avant vectorisation), le Postgres Trigger remplace directement ce cron : chaque INSERT dans la table déclenche immédiatement le découpage, l'embedding et l'insertion dans pgvector décrits dans notre guide RAG avec Supabase. Le document est interrogeable par le chatbot en quelques secondes plutôt qu'à la prochaine exécution planifiée. C'est exactement l'architecture que fournit prêt à l'emploi le Pack Assistant RAG (119 €), sur laquelle brancher ce déclencheur en temps réel ne change que le point d'entrée du pipeline.

Cas d'usage concret : qualifier un lead dès son écriture en base

Quand un lead arrive d'un système qui écrit directement en base plutôt que via un webhook — un ERP interne, un formulaire déjà relié à Postgres, une synchronisation nocturne devenue temps réel — le Postgres Trigger déclenche instantanément le scoring par IA détaillé dans notre guide de qualification automatique des leads, sans attendre le prochain passage d'un cron. La même mécanique de scoring et de routage équipe le Pack Inbox IA (79 €) pour les emails entrants ; remplacer le déclencheur email par un Postgres Trigger sur une table de leads ne change que la source du signal.

Cas d'usage concret : tracer un changement sensible en temps réel

Pour une activité soumise à des obligations de traçabilité, un Postgres Trigger posé sur une table sensible (dossiers d'audit, contrats, statuts de conformité) permet de notifier instantanément un canal Slack ou de dupliquer chaque modification vers une table de piste d'audit, dans la lignée de notre guide sur la piste d'audit RGPD avec Supabase. L'enjeu de l'intégrité de ce type de journal n'est pas nouveau : Snodgrass, Yao et Collberg, dans « Tamper Detection in Audit Logs » présenté à VLDB en 2004, montrent qu'un journal d'audit n'a de valeur probante que s'il est possible de détecter toute modification a posteriori — ce qui plaide pour que la notification déclenchée par le trigger écrive vers une table append-only distincte plutôt que de se contenter d'alerter sans laisser de trace durable. C'est précisément le principe qu'implémente le Pack Conformité & Audit (149 €).

Limites à connaître avant de s'appuyer dessus en production

Le Postgres Trigger n'est pas une file d'attente durable : LISTEN/NOTIFY ne persiste rien, et si aucun workflow n'écoute au moment du NOTIFY — instance arrêtée, workflow désactivé, coupure réseau —, l'événement est perdu sans retry automatique. Pour les cas où c'est inacceptable, gardez un filet de sécurité : une colonne updated_at sur la table et une resynchronisation périodique peu fréquente qui rattrape les écarts, sur le même principe que la resynchronisation complète décrite dans notre guide RAG. Gardez aussi en tête que chaque workflow actif utilisant ce node maintient une connexion Postgres ouverte en permanence : sur une instance en mode queue avec plusieurs workers, ou sur un pool de connexions déjà sous tension, c'est un paramètre à surveiller plutôt qu'un détail.

En résumé

Le Postgres Trigger transforme une base PostgreSQL que vous contrôlez en véritable source d'événements pour n8n, sans cron ni webhook applicatif à maintenir : n8n crée et gère lui-même le trigger et la procédure nécessaires, le mode simple couvre l'essentiel des besoins, et le mode Listen to Channel prend le relais pour une logique de déclenchement plus riche. La seule vraie vigilance porte sur les permissions PostgreSQL du credential et sur l'absence de garantie de livraison en cas d'interruption — deux points à vérifier avant de bâtir une architecture critique dessus. Pour un pipeline documentaire ou une piste d'audit qui bénéficieraient directement de ce temps réel, les Pack Assistant RAG et Pack Conformité & Audit fournissent la suite du pipeline prête à importer, et le Bundle FlowKit Complet (269 € au lieu de 347 €) réunit les trois packs pour qui veut couvrir emails, documents et conformité d'un même mouvement.