Skippr Docs

Appearance

When to Use ClickHouse as a Warehouse Destination ​

May 2026

ClickHouse is the right warehouse destination when fast analytical reads matter and the team is comfortable with ReplacingMergeTree-based final-state convergence.

Short Answer ​

Use ClickHouse as a warehouse destination when the team wants warehouse-speed analytical reads and is comfortable with final-state reconciliation that converges through ReplacingMergeTree semantics rather than immediate in-place updates. This destination fits best when query consumers already understand ClickHouse and can distinguish between freshly inserted versions and fully merged current state.

A practical example is a product analytics team that needs very fast queries over current account, subscription, or event-derived entities. Skippr can land those rows into ClickHouse, attach _skippr_order_token values, and let ReplacingMergeTree keep the newest version for each key during merges, while analysts use FINAL for point-in-time correctness on newly written data.

Why Teams Struggle with This ​

ClickHouse is powerful, but it is a bad fit for teams that expect every upsert to look immediately deduplicated in every query. The destination docs are clear that deduped state can appear delayed, which means the query model has to be part of the warehouse decision.

  • Freshly written data may still show duplicate versions until background merges complete.
  • Readers who need immediate correctness on recent writes have to know when to use FINAL.
  • The ClickHouse user still needs write access to the target database and tables, and the HTTP endpoint has to be reachable.
  • If the team wants a warehouse that behaves like synchronous row replacement with no explanation needed, ClickHouse usually creates avoidable confusion.

How Skippr Handles It ​

Skippr makes ClickHouse workable as a CDC destination by leaning into its documented behavior instead of hiding it. The connector writes over HTTP, creates _skippr_order_token columns and tombstone tables automatically, and relies on ClickHouse final-state reconciliation rather than pretending every query will see a deduped answer instantly.

That is useful when you want speed without losing discipline. The integration has a clear rule for which version should win, and the warehouse behavior is explicit enough to document for analysts and application teams.

  • Writes to ClickHouse over the HTTP interface.
  • Uses ReplacingMergeTree-based final-state CDC reconciliation.
  • 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 ClickHouse database, one destination table fed by a source with a stable key, and one query check that compares regular reads with FINAL immediately after updates.

ClickHouse is a bad fit when warehouse consumers will treat delayed merge visibility as broken data or when no one wants to own the extra education that comes with that read model.