Skippr Docs

Appearance

How ReplacingMergeTree Works for ClickHouse CDC Final State ​

April 2026

ClickHouse CDC is easier to operate when you understand what ReplacingMergeTree does and what it does not do for you.

Short Answer ​

ReplacingMergeTree helps ClickHouse converge on the latest version of a row, but it is not magic. You still need a clear ordering signal and a clear idea of what counts as row identity.

In Skippr, the useful framing is simple: ClickHouse storage behavior is part of the CDC design. It is not just a detail the warehouse will sort out later.

Why Teams Struggle with This ​

Teams often hear "ReplacingMergeTree deduplicates rows" and assume the warehouse will repair every replay problem automatically. That is too optimistic.

  • A missing or weak version column leaves ClickHouse with no reliable way to prefer one change over another.
  • A weak business key means the destination cannot tell two logical rows apart.
  • Readers can query a table before background merges have converged.
  • Delete handling still needs a deliberate strategy.

How Skippr Handles It ​

Skippr is useful here because it keeps the source event model and the ClickHouse table design close together. The team can review ordering assumptions, key choice, and warehouse behavior as one conversation.

That usually leads to fewer surprises once the first generated dbt models start depending on the table.

  • CDC configuration can reflect the ordering signal the warehouse needs.
  • Business-key choices are reviewed before they leak into analytics models.
  • ClickHouse behavior is treated as a design input, not a hidden implementation detail.
  • The generated dbt project starts from a more deliberate table contract.

What the First Useful Version Looks Like ​

ReplacingMergeTree is powerful when you use it with intent. It is frustrating when it is asked to compensate for a fuzzy CDC design.

That distinction is the whole page.