Postgres can push a notification. Something still has to listen.

What LISTEN/NOTIFY actually does

Postgres has a real pub/sub mechanism built in. A trigger calls pg_notify() when a row changes, and any client that's issued LISTEN on that channel gets the payload the moment it's sent, no polling delay. A trigger and function that fire on every order change:

CREATE OR REPLACE FUNCTION notify_order_change() RETURNS trigger AS $$
BEGIN
  PERFORM pg_notify('order_changes', row_to_json(NEW)::text);
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER order_change_trigger
AFTER INSERT OR UPDATE ON orders
FOR EACH ROW EXECUTE FUNCTION notify_order_change();

A client then does the other half:

LISTEN order_changes;
-- a persistent connection blocks here, waiting for the next NOTIFY payload

The part that's easy to skip past

That last line is the catch. Something has to hold that connection open, permanently, listening. If the listener process crashes, redeploys, or your laptop goes to sleep, every NOTIFY sent while it's down is gone. Postgres doesn't queue notifications for a disconnected listener, there's no replay when it reconnects. The payload is also capped at 8000 bytes, so it works for a row ID or a small JSON diff, not a full row dump on a wide table. LISTEN/NOTIFY is genuinely fast, but it's push infrastructure you have to run and supervise, not a free feature.

If you just want to know when something changed

If the actual goal is "tell me when this changed," not "push it to my running application in under a second," a Watch skips the listener entirely. QueryFlow re-runs your saved query on a schedule and compares the result; nothing has to stay connected between checks.

Before you start

A query that returns the row or value you care about, and QueryFlow Pipelines.

Steps

1. Run the query you want to keep an eye on, then click Watch this.
2. Name it, and confirm the Connection and SQL.
3. Choose what to watch: Any change for a row like the example below, or A value for one column.
4. Pick a Condition: Changed is the direct equivalent of "tell me when this is different."
5. Set Check every, choose Destinations, and Save.

A worked example

SELECT id, status, updated_at
FROM public.orders
WHERE id = 48213;

Watch Any change on this, Check every 15m, destination Slack. Every 15 minutes QueryFlow re-runs the query and compares the row to the last check; the moment status or updated_at differs, a message goes to Slack. No trigger to write, no listener process to keep alive.

Check it worked

Use Run preview before saving to confirm the current row. After saving, change the row's status manually and use Check now from the Watches list to confirm the alert actually fires and reaches Slack.

Troubleshooting

A large payload doesn't fit through NOTIFY anyway

The trigger example above sends the whole changed row as JSON, which works until the row gets wide. A NOTIFY payload is capped at 8000 bytes, so a table with a large text column or many fields needs the trigger to send a smaller payload, an ID and a couple of fields, and have the listener query the full row itself. A Watch has no equivalent limit to think about, since it's just reading the query's normal result, not packing it into a notification channel.

Using both together

These aren't strictly either-or. A team running LISTEN/NOTIFY inside an application can still add a Watch on the same table as a safety net: if the listener process ever goes down for an extended period, deploys, crashes, gets rescheduled, the Watch still catches the change on its own schedule and sends an alert, even though the application itself missed the instant push. The Watch is slower but it has nothing that can silently stop working the way an unmonitored listener process can.

Which one to actually use

Use LISTEN/NOTIFY when you're already running a persistent application process and need a change pushed into it in under a second, that's what it's built for. Use a Watch when you want to know about a change and you're fine hearing about it within a few minutes, without standing up or supervising a listener at all. Most "did this change" questions that end up in Slack or email are the second case.