Use Debezium to trigger a flow whenever new entries hit a Postgres

Capture row-level changes from a Postgres database in near real time using Debezium change data capture (CDC), then react to those changes inside a Kestra flow. Instead of polling tables on a fixed schedule or wiring up a standalone Debezium connector and a separate consumer, this blueprint turns every insert into an event that drives notifications and downstream processing. It solves the classic problem of keeping systems in sync the moment data lands, without building bespoke streaming infrastructure.

How it works

A io.kestra.plugin.debezium.postgres.Trigger connects to Postgres over the logical replication stream (pluginName: PGOUTPUT) and watches for committed changes. It uses snapshotMode: INITIAL to read existing rows on first run, format: INLINE to embed captured records, and polls every PT30S (interval). When new rows arrive, the trigger fires a flow execution and exposes the captured data through trigger.uris and a row count via trigger.size.

1. slack_notificaiton (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a message reporting how many new rows were added ({{ trigger.size }}).
2. json (io.kestra.plugin.serdes.json.IonToJson) converts the captured Ion records from trigger.uris['postgres.order'] into JSON.
3. python (io.kestra.plugin.scripts.python.Script) loads the JSON output and processes the records.

What you get

• Event-driven reactions to Postgres inserts, updates, and deletes
• Automatic Slack alerts with live row counts
• Captured CDC data converted to JSON and ready for custom Python logic
• A reproducible local setup with Debezium Postgres and Adminer

Who it's for

• Data engineers building real-time ingestion and sync pipelines
• Backend teams who need to fan out database events to other systems
• Platform teams replacing brittle polling jobs with CDC

Why orchestrate this with Kestra

Debezium streams changes, but it does not orchestrate what happens next. Kestra adds an event trigger that launches a full workflow on every change, retries on transient failures, captures execution lineage and outputs, and keeps the whole pipeline as declarative YAML you can version and review. The native scheduler in a database (cron or pg_cron) cannot react the instant a row commits, fan out to Slack and Python in one run, or give you per-execution observability the way an orchestrated flow can.

Prerequisites

• A Kestra instance with the Debezium, Slack, SerDes, and Python plugins available
• A reachable Postgres database configured for logical replication
• Python available to the script task runner

Secrets

• SLACK_WEBHOOK: the Slack incoming webhook URL used by the notification task

Quick start

1. Start a local Postgres with CDC enabled, for example with this docker-compose.yml:

   services:
     db:
       image: debezium/postgres:latest
       restart: always
       environment:
         POSTGRES_PASSWORD: example
       ports:
         - 5433:5432
   
     adminer:
       image: adminer
       restart: always
       ports:
         - 8082:8080
   

2. Open localhost:8082 to create tables via Adminer (the database listens on port 5433).

3. Define the SLACK_WEBHOOK secret in Kestra.

4. Add this flow, insert rows into your table, and watch the trigger fire within the PT30S interval.

How to extend

• Point trigger.uris at your own table instead of postgres.order
• Adjust snapshotMode, pluginName, or interval to match your database setup
• Replace the Python script with dbt, a database load, or an API call
• Route notifications to other channels or add conditional alerting on trigger.size

Links

• Plugin docs: https://kestra.io/plugins/plugin-debezium