Skip to main content
Connic

PostgreSQL

By Connic

Connic listens on a Postgres NOTIFY channel and triggers your agent the moment a row arrives. No polling, no CDC pipeline, no extra service to keep alive: your database becomes the event source.

Inbound

Overview

PostgreSQL ships with a built-in pub/sub mechanism: LISTEN/NOTIFY. A trigger function or your 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 your database, subscribes to the channel you configure, 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. Your database already knows when a row changed; the connector just puts an agent on the other end of that signal.

How it works

1

Make the database reachable

Your PostgreSQL server must be reachable from the internet, or you can use the Connic Bridge to connect databases inside private networks.

2

Add a NOTIFY trigger

Create a trigger function that calls pg_notify() on the table you want to monitor, or send notifications directly from application code. A JSON payload with the row data is the common pattern.

3

Create the connector

Add a PostgreSQL connector from your agent's Connector Flow and enter host, port, database, username, password, the channel name, and SSL settings. Connic starts listening on the channel immediately.

What you can build

Patterns teams ship in production. No queues, workers, or schedulers to run.

Trigger

New customer row inserted

NOTIFY customers_insert
Agent Action

Agent looks up the company on Clearbit, fills in firmographics, and writes the result back to the customer row before the welcome email goes out.

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 you can use a dedicated low-privilege user. SSL mode is configurable (disable, prefer, or require). Each connector maintains a single persistent connection per channel, which is worth knowing if your 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
Category
Connectors
Modes
Inbound
Documentation
PostgreSQL docs

Frequently Asked Questions

How do I trigger an AI agent when a row is inserted in Postgres?

Create a trigger function on the table that calls 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.

Does the connector poll my database?

No. The connector maintains a persistent connection and subscribes to a NOTIFY channel with LISTEN, so events are pushed by PostgreSQL the moment they happen. There is no polling interval, no repeated queries against your tables, and only a single connection per channel.

Can Connic connect to a database inside a private network?

Yes. If your PostgreSQL server is not reachable from the internet, the Connic Bridge connects databases inside private networks to your connectors without exposing the database publicly. Learn how the Connic Bridge works.
Need PostgreSQL in a production agent flow?

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