Skippr Docs

Appearance

When ClickHouse Is the Right Final-State Destination ​

July 2026

ClickHouse is the right final-state destination when warehouse speed matters enough that the team is willing to own the read-model details that come with ReplacingMergeTree.

Short Answer ​

ClickHouse is the right final-state destination when the team wants ClickHouse-class analytical performance and understands the documented CDC trade-off: final state converges through ReplacingMergeTree semantics rather than immediate in-place row replacement. The destination docs and CDC docs are aligned on this point, including the warning that recent duplicates may remain visible until background merges complete and FINAL is needed for point-in-time correctness on fresh data.

That makes ClickHouse a strong fit for teams already centered on ClickHouse analytics who still want final-state CDC tables. A product analytics group can land current account or subscription entities into ClickHouse and get extremely fast queries, as long as they are prepared to explain when hot data queries should use FINAL.

Why Teams Struggle with This ​

ClickHouse is a poor fit when the team expects every query to behave like a generic MERGE-first warehouse with no engine-specific caveats. The performance profile is excellent, but the read model has to be part of the decision rather than an afterthought.

  • Freshly written data may show multiple versions until background merges complete.
  • Readers who need immediate correctness on recently changed keys must know when to use FINAL.
  • The ClickHouse user still needs write access to the target database and a reachable HTTP endpoint.
  • If no one wants to document the warehouse-specific query trade-off, ClickHouse usually creates confusion instead of leverage.

How Skippr Handles It ​

Skippr makes ClickHouse workable by leaning into the documented behavior instead of hiding it. The destination connector writes over HTTP, and the CDC destination docs explain how _skippr_order_token and tombstone tables interact with ReplacingMergeTree to preserve logical final state under retries and deletes.

That gives teams a clear mental model: writes converge to the newest row version, deletes are protected, and fresh correctness-sensitive reads may need FINAL. It is a real trade-off, but it is a trade-off the docs make explicit.

  • Writes to ClickHouse over the documented HTTP interface.
  • Uses ReplacingMergeTree semantics for final-state CDC convergence.
  • Automatically manages order-token columns and tombstone tables.
  • Supports point-in-time correctness on fresh data through FINAL queries.

What the First Useful Version Looks Like ​

The first useful version is one database, one CDC-managed table with a stable business key, and one query check that shows how ordinary reads differ from FINAL immediately after updates.

If the team wants fast analytics but none of the engine-specific query discipline, pick a different final-state destination rather than fighting ClickHouse into pretending it is one.