The Postgres Trigger node in n8n: firing a workflow in real time from a PostgreSQL database

A row inserted into a "leads" table should kick off AI-based qualification. A new document dropped into your knowledge-base table should re-trigger RAG indexing. An audit answer saved to the database should instantly update a tracking dashboard. In every one of these cases, the event source is a PostgreSQL database you fully control — and yet the most common reflex is still to poll the table every five minutes with a Schedule Trigger. n8n's Postgres Trigger node removes that detour: it wires the workflow directly into PostgreSQL's native LISTEN/NOTIFY mechanism, with no polling and no application-level webhook to hand-build.

Why polling is the wrong answer here

For a third-party API you don't control, polling is sometimes the only option available — our guide on automating without a webhook via smart polling covers how to build that cleanly when it's the case. But when the source is a PostgreSQL database you administer yourself, forcing a periodic polling cycle means voluntarily giving up a capability the database already offers natively. The literature on event-driven architectures documents this gap precisely: the survey paper by Eugster, Felber, Guerraoui and Kermarrec, "The Many Faces of Publish/Subscribe," published in ACM Computing Surveys in 2003, formalizes why a push-based notification model (publish/subscribe) decouples producers and consumers of events better than periodic polling, while reducing end-to-end latency and unnecessary load on the source. LISTEN/NOTIFY is PostgreSQL's native implementation of that model, and the Postgres Trigger node is simply a way to wire it into an n8n workflow.

How the node works under the hood

Unlike the standard Postgres node (see our guide to SQL queries with the Postgres node) which runs queries on demand, the Postgres Trigger stays permanently connected and waits. Concretely, when the workflow is activated, n8n automatically creates two objects on the database side: a trigger on the watched table and an associated procedure that trigger calls. That procedure fires a NOTIFY on a dedicated channel for every matching operation, and the n8n node — sitting in LISTEN mode on that same channel through a dedicated Postgres connection — receives the event and starts the workflow execution, typically within milliseconds.

The important thing to remember: the trigger and the procedure only exist while the workflow is active. Deactivating the workflow removes them automatically; reactivating it recreates them. That's convenient for not leaving anything dangling in the database, but it also means no event that occurred during a deactivation window gets caught up afterward — see the FAQ for the workaround.

The two configuration modes

Listen and Create Trigger Rule

This is the default mode, built for the common case: you pick a table and one or more operations to watch (INSERT, UPDATE, DELETE), and n8n generates all the necessary SQL itself — trigger and procedure included. No SQL to write on your end. This mode covers the vast majority of use cases: "fire the workflow on every new row in documents," for instance.

Listen to Channel

This second mode targets more specific needs: you supply directly the name of a NOTIFY channel that your own PostgreSQL triggers or functions feed. Reach for this mode as soon as the firing logic goes beyond "one operation on one table" — combining several tables, adding a business condition inside the procedure before notifying, or aggregating several writes into a single notification. It requires writing the PostgreSQL trigger yourself, but gives you full control over what actually fires the workflow.

The PostgreSQL permissions to check before promising anything

This is the point that most often breaks a live demo: for n8n to create the trigger and procedure on activation, the credential's user needs the TRIGGER privilege on the table (or ownership of it), plus the CREATE privilege on the target schema. On a self-hosted Postgres instance you administer — the one from our PostgreSQL setup guide for n8n, for example — this is never an issue: the application role generally owns its own tables. On a managed database, on the other hand, check ahead of time: the default postgres role provisioned on a Supabase project typically has the required rights, but some cloud offerings deliberately restrict trigger creation for governance reasons. A test activation in a non-production environment avoids an unpleasant surprise in production.

Concrete use case: re-indexing a RAG pipeline without a cron job

A typical RAG pipeline watches for new documents with a Schedule Trigger that polls the source periodically — see our guide on keeping a RAG index up to date with n8n. If your documents pass through an intermediate Postgres table (an ERP import, a PDF extraction saved to the database before vectorization), the Postgres Trigger replaces that cron job directly: every INSERT into the table immediately triggers the chunking, embedding and insertion into pgvector described in our RAG with Supabase guide. The document becomes queryable by the chatbot within seconds instead of at the next scheduled run. This is exactly the architecture the RAG Assistant Pack (€119) provides ready to import, and wiring in this real-time trigger only changes the pipeline's entry point.

Concrete use case: qualifying a lead the moment it's written

When a lead arrives from a system that writes directly to the database rather than through a webhook — an internal ERP, a form already wired to Postgres, an overnight sync turned real-time — the Postgres Trigger instantly fires the AI-based scoring detailed in our guide to automatic lead qualification, without waiting for the next cron run. The same scoring and routing mechanics power the AI Inbox Pack (€79) for inbound emails; swapping the email trigger for a Postgres Trigger on a leads table only changes the signal's source.

Concrete use case: tracing a sensitive change in real time

For an activity subject to traceability obligations, a Postgres Trigger placed on a sensitive table (audit case files, contracts, compliance statuses) lets you instantly notify a Slack channel or duplicate every change into an audit-trail table, in the same spirit as our GDPR audit trail with Supabase guide. The integrity of this kind of log is not a new concern: Snodgrass, Yao and Collberg, in "Tamper Detection in Audit Logs," presented at VLDB in 2004, show that an audit log only has probative value if any post-hoc modification can be detected — which argues for having the trigger's notification write to a distinct append-only table rather than just raising an alert with no durable trace. That is precisely the principle the Compliance & Audit Pack (€149) implements.

Limits to know before relying on this in production

The Postgres Trigger is not a durable queue: LISTEN/NOTIFY persists nothing, and if no workflow is listening at the moment of the NOTIFY — instance down, workflow deactivated, network blip — the event is lost with no automatic retry. For cases where that's unacceptable, keep a safety net: an updated_at column on the table and an infrequent periodic resync that catches up on gaps, following the same principle as the full resync described in our RAG guide. Also keep in mind that every active workflow using this node keeps a Postgres connection open permanently: on an instance running in queue mode with several workers, or on a connection pool already under pressure, that's a parameter to watch rather than a detail.

In summary

The Postgres Trigger turns a PostgreSQL database you control into a genuine event source for n8n, with no cron job or application webhook to maintain: n8n creates and manages the necessary trigger and procedure itself, the simple mode covers most needs, and Listen to Channel mode steps in for richer firing logic. The real things to watch are the credential's PostgreSQL permissions and the lack of delivery guarantees during downtime — two points worth checking before building anything critical on top of this. For a document pipeline or an audit trail that would directly benefit from this real-time signal, the RAG Assistant Pack and Compliance & Audit Pack provide the rest of the pipeline ready to import, and the Complete FlowKit Bundle (€269 instead of €347) bundles all three packs for anyone looking to cover email, documents and compliance in one move.