Database Listener
Run an automation when a SQL query returns new, changed or removed rows.
What it does
Runs a SELECT statement at a fixed interval and compares the result with the last known state. New rows start a run; with a key column it also recognizes changed rows (including which columns changed) and, if you want, removed rows.
The first start only records the current state — existing rows do not start runs (unless you ask for it). The state survives restarts: changes made while the AI Kit was down are reported at the next start.
The listener only reads. Statements other than a single SELECT are rejected.
What you configure
| Field | What it controls | Required | Notes |
|---|---|---|---|
| Database type | postgres, mysql (also MariaDB), mssql (SQL Server) or sqlite. | required | |
| Server / Port | Where the database runs. | required except SQLite | Default ports 5432 / 3306 / 1433. |
| User / Password | Login for the database. | as the database needs | The password is stored encrypted. |
| Database | Database name. | required | SQLite: absolute file path on the server, or a libSQL address. |
| Encrypted connection (TLS) | Connect via TLS. | optional | Off by default, on for SQL Server. |
| Query | The SELECT whose result is watched. | required | |
| Key column | Column that identifies a row, e.g. id. | optional | Needed to detect changed and removed rows. Without it only new rows are detected. |
| New rows / Changed rows / Removed rows | Which changes start runs. | optional | New and changed on, removed off by default. |
| Runs | per-run: one run with all changes · per-row: one run per row. | optional | Default per-run. |
| Existing rows count as new on first start | Report the whole result once at the first start. | optional | Default off. |
| Poll interval (ms) | How often the query runs. | optional | Default 60 000 (once per minute), at least 5 000. |
| Max. rows of the query | Upper limit for the result. | optional | Default 10 000. A larger result is not compared — the listener reports an error instead of treating the rest as removed. |
| Max. changes per check | Upper limit per run. | optional | Default 500; the rest follows at the next check. |
| Result (rows) | Memory output with the new and changed rows. | required | A list (per-row: the one row). |
| Changes (details) | Memory output with the details. | optional | { count, added, changed, removed, changes: [{ changeType, key, row, previous, changedFields }] } |
📷 SCREENSHOT: The Database Listener configuration with connection, query and key column.
Example scenario
React to paid orders. Watch SELECT id, customer, status, total FROM orders WHERE created_at > CURRENT_DATE - 30 with key column id. When an order's status changes to paid, the run gets the order under Result (rows) and the changed column under Changes (details); a condition on the next step checks for paid, an AI action drafts the invoice e-mail and Send E-Mail delivers it.
Recommendations
- ✅ Use a key column whenever the table has one — otherwise updates stay invisible.
- ✅ Keep the result small with a time filter (e.g. the last 30 days). The whole result is compared at every check.
- ✅ Use a dedicated read-only user for this connection.
- ✅ Start with a longer poll interval (e.g. 5 minutes) and shorten it only if you need faster reactions.
- ❌ Do not select columns that change on every read (e.g.
NOW()) — every row would count as changed.
What to do next
- To read or write data from inside the workflow: Database Query.
- For exported files instead of a database: Records changed.