Skippr Docs

Appearance

Kafka CDC to ClickHouse Final-State Guide ​

June 2026

Kafka to ClickHouse CDC is most reliable when the team understands both Debezium envelopes and ClickHouse merge timing.

Short Answer ​

Kafka CDC reaches ClickHouse final state by parsing Debezium envelopes on the source side and using ReplacingMergeTree on the destination side. Skippr reads create, update, and delete messages from Kafka, extracts the key fields and payload, and inserts row versions into ClickHouse with an order token that lets newer versions win during merges.

The destination-specific caution is that ClickHouse converges over time. If a Debezium update for customer_id = 42 arrives after an earlier create, both versions may be visible briefly until a merge runs. That is why the documentation should tell readers when to use FINAL for immediate correctness.

Why Teams Struggle with This ​

This integration is easy to misread because both systems are fast. Speed does not remove the need to explain what a correct row looks like right after a fresh mutation.

  • Kafka offsets tell you where consumption resumed, but not which row version should win in the warehouse.
  • Debezium before and after fields need to be mapped into one logical business key.
  • Delete messages still need tombstone tracking before target deletion.
  • ClickHouse readers can mistake pre-merge duplicates for pipeline errors.

How Skippr Handles It ​

Skippr uses a stable consumer group for Kafka resume and parses the Debezium envelope directly, so the source path stays faithful to the topic contract the docs describe.

For ClickHouse, Skippr adds _skippr_order_token, uses ReplacingMergeTree for versioned rows, and records deletes in tombstone tables. That keeps convergence, not instant overwrite, as an explicit part of the integration design.

  • Debezium topics are consumed with durable offset tracking.
  • Key fields from Kafka messages become the row identity ClickHouse reconciles on.
  • ReplacingMergeTree keeps the newest row version during merges.
  • FINAL remains available when readers need point-in-time correctness.

What the First Useful Version Looks Like ​

Choose this integration when Kafka is already central to CDC delivery and ClickHouse is the destination for low-latency analytics.

The design success criterion is not just that messages arrive. It is that the team understands exactly when the ClickHouse table has converged and how to query it before then.