Postgres Workflows in n8n: Patterns and Pitfalls
Use Postgres as both n8n's database and a workflow tool. Triggers, NOTIFY/LISTEN, upserts, and transactions.
Key takeaways
- Use the Postgres Trigger node with LISTEN/NOTIFY for real-time row events.
- Always use parameterized queries — never string-concatenate user input.
- ON CONFLICT DO UPDATE is your upsert friend.
- Wrap multi-statement writes in a transaction via the Code node when needed.
Postgres is the workhorse behind production n8n. Beyond storing executions, it can be your trigger, your queue, your dead-letter store, and your durable cache. These patterns separate hobby usage from real engineering.
Real-time triggers with LISTEN/NOTIFY
Add a Postgres trigger that fires NOTIFY new_lead, row::text on INSERT. The n8n Postgres Trigger node subscribes and fires the workflow within milliseconds — no polling, no quota burn.
Idempotent upserts
INSERT INTO contacts (email, name) VALUES ($1, $2) ON CONFLICT (email) DO UPDATE SET name = EXCLUDED.name, updated_at = NOW(). The single most useful pattern for sync workflows.
Postgres as a queue
SELECT ... FOR UPDATE SKIP LOCKED turns a table into a multi-worker job queue. Combine with a cron-triggered workflow that runs every minute and your n8n becomes a durable job processor.
Frequently asked questions
- Should I use Supabase or plain Postgres with n8n?
- Either. Supabase is great for the auth + realtime + pgvector combo. Plain Postgres is leaner and cheaper if you only need the database.
- How do I run a transaction in n8n?
- Use the Postgres node's Execute Query mode with BEGIN/COMMIT/ROLLBACK or wrap calls in a Code node using the pg client.