Queries icon
Script icon
Docker icon
Query icon
If icon
Fail icon
Schedule icon

Materialize Kafka keyed state in PostgreSQL with atomic checkpoints

Materialize Kafka keys in PostgreSQL with tombstones, bounded batches, and atomic database checkpoints that survive retries.

Categories
Data

Build a queryable latest-value table from a compacted Kafka topic. Values and read positions commit together, so a failed batch can be read again.

How it works

  1. Create PostgreSQL tables and a live view; poll each minute when enabled.
  2. Lock the topic, assign its partitions from database offsets, and read a bounded batch. No Kafka group offsets are committed.
  3. Upsert JSON values by key. A null Kafka value saves a tombstone; JSON null remains a live value. Commit rows and next offsets together.
  4. Check that durable offsets cover every stored record.

What you get

  • kafka_state.current_values: latest live values by topic and UTF-8 key.
  • A batch report with counts and next offsets, without message payloads.
  • Rollback on invalid data, moved keys, changed topic IDs or database errors.

Who it's for

Data engineers who need a SQL view of keyed Kafka state for joins or reports.

Why orchestrate this with Kestra

Bound each execution, retain its report, and retry failed batches. PostgreSQL holds the durable progress; a transaction lock also excludes other writers that use this blueprint against the same destination.

Prerequisites

Kestra 2.0, PostgreSQL, Kafka with topic IDs, a Docker runner, and network access from the worker and script containers (set docker_network). Use one Kafka cluster per destination, compact-only topics, stable key partitioning and a fixed partition count. Keep up with delete.retention.ms: compacted-away tombstones cannot be recovered by this flow. This is a batch materializer, not a Kafka Streams replacement.

Secrets

  • KAFKA_STATE_PROPERTIES: Kafka client JSON, including bootstrap.servers and any TLS/SASL settings. Mount certificate files if needed.
  • KAFKA_STATE_JDBC_URL and KAFKA_STATE_DSN: JDBC and libpq connections to the same database; keep credentials in the two secrets below.
  • KAFKA_STATE_USER and KAFKA_STATE_PASSWORD: schema/table owner credentials.

Quick start

  1. Set the six secrets and import the flow. Leave the schedule disabled.
  2. Execute for a topic with string keys and JSON values. Query the live view.
  3. Update a key and send a Kafka tombstone; execute again and check both.
  4. Set batch bounds to keep up with traffic, then enable the schedule.

How to extend

Add a downstream SQL model or lag alerts. Restore rows and positions together. After topic recreation, a partition change or missed tombstone retention, stop writers and rebuild into empty state; never reset offsets alone.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.