PostgreSQL
Connic listens on a Postgres NOTIFY channel and triggers the agent the moment a row arrives. No polling, no CDC pipeline, no extra service to keep alive: the database becomes the event source.
Overview
PostgreSQL ships with a built-in pub/sub mechanism: LISTEN/NOTIFY. A trigger function or application code calls pg_notify() on a channel, and every connection listening on that channel receives the payload instantly. The PostgreSQL connector holds a persistent connection to the database, subscribes to the configured channel, and turns each notification into an agent run carrying the notification payload.
That replaces the usual machinery for reacting to data changes: no polling loop hammering the table, no change-data-capture pipeline, no worker service to deploy and monitor. The database already knows when a row changed; the connector puts an agent on the other end of that signal.
How it works
Make the database reachable
The PostgreSQL server must be reachable from the internet, or the Connic Bridge can connect databases inside private networks.
Add a NOTIFY trigger
Create a trigger function that calls pg_notify() on the table to monitor, or send notifications directly from application code. A JSON payload with the row data is the common pattern.
Create the connector
Add a PostgreSQL connector from the agent's Connector Flow and enter host, port, database, username, password, the channel name, and SSL settings. Connic starts listening on the channel immediately.
Production patterns
Patterns teams ship in production, with Connic running the queues, workers, and schedulers.
New customer row inserted
NOTIFY customers_insertAgent looks up the company on Clearbit, fills in firmographics, and writes the result back to the customer row before the welcome email goes out.
New customer row inserted
NOTIFY customers_insertAgent looks up the company on Clearbit, fills in firmographics, and writes the result back to the customer row before the welcome email goes out.
Order placed
NOTIFY orders_insertAgent scores fraud risk against past behavior, drafts a tailored follow-up email, and updates inventory forecasts from the row insert event.
Order placed
NOTIFY orders_insertAgent scores fraud risk against past behavior, drafts a tailored follow-up email, and updates inventory forecasts from the row insert event.
User content saved
NOTIFY content_insertAgent reads the new row, checks for policy violations, and sets a moderation flag column before the post is rendered to other users.
User content saved
NOTIFY content_insertAgent reads the new row, checks for policy violations, and sets a moderation flag column before the post is rendered to other users.
Record inserted
NOTIFY records_insertAgent runs the row through the configured business rules, cross-checks it against external sources, and writes corrections or flags at write time, before a Tuesday batch job can find the bad data.
Record inserted
NOTIFY records_insertAgent runs the row through the configured business rules, cross-checks it against external sources, and writes corrections or flags at write time, before a Tuesday batch job can find the bad data.
Connection and credentials
The connector authenticates with a standard database user and password. That user only needs CONNECT permission on the database; receiving NOTIFY events requires no table access and no special grants, so a dedicated low-privilege user is sufficient. SSL mode is configurable (disable, prefer, or require). Each connector maintains a single persistent connection per channel, which is worth knowing if the database enforces tight connection limits.
Every notification becomes a normal agent run: it shows up in run history with full traces, token and cost tracking, and the same guardrails and approval rules as any other trigger.
Payload shape and limits
The agent receives the notification payload plus a _postgres metadata block with the channel name, backend process ID, and timestamp. With Parse JSON Payload enabled (the default), a JSON notification arrives as a structured object rather than a string. PostgreSQL caps NOTIFY payloads at 8000 bytes, so the reliable pattern is to send IDs and key fields and let the agent fetch the full record. Separate channels per event type, like orders_created and users_updated, keep routing clean. See trigger examples and the full payload format in the PostgreSQL docs.
Information
- Publisher
- By Connic
- Connectors
- Connectors
- Modes
- Inbound
- Documentation
- PostgreSQL docs
Frequently Asked Questions
pg_notify() with a JSON payload, then point a Connic PostgreSQL connector at that channel. Every insert fires a notification, and the connector turns it into an agent run with the payload as input. Updates and deletes work the same way with an AFTER UPDATE or AFTER DELETE trigger. For more trigger-to-agent patterns, read the connector patterns guide.Bring the event source, payload shape, result destination, and any private-network or approval requirements. We will map PostgreSQL to the right Connic connector mode, deployment path, and observability setup.
Talk to Sales