Skippr Docs

Appearance

How to Explain ClickHouse Tables to Analysts ​

July 2026

Analysts should understand that Skippr ClickHouse tables are current-state tables, but very recent updates can briefly show duplicate versions until merges complete.

Short Answer ​

Explain ClickHouse tables as current-state tables that converge through ReplacingMergeTree behavior rather than as tables that look fully deduplicated the instant a write lands. Skippr stores CDC-managed rows with _skippr_order_token ordering, so the table is designed to settle on the latest version per key, but very recent updates can still appear as multiple versions until background merges complete.

That is the key analyst expectation to teach plainly. If accounts receives an update and an analyst queries right away, they may briefly see both the older row and the newer row unless they use FINAL. Once merges catch up, the ordinary table view converges. The system fields and tombstones are there to preserve correctness, but the immediate read model is not identical to a synchronous row-replacement database.

Why Teams Struggle with This ​

ClickHouse confusion usually comes from calling the destination current-state without mentioning how that current state becomes visible. Analysts do not need the engine internals, but they do need one clear sentence about recent duplicates and FINAL.

  • Recent writes can show duplicate versions temporarily because deduped state depends on background merges.
  • FINAL is the query tool analysts use when they need point-in-time correctness on freshly updated data.
  • The _skippr_order_token column explains which version should win, but it is not a business metric.
  • Tombstone tables support delete safety and should not be confused with a user-facing deletion history table.

How Skippr Handles It ​

Skippr is unusually explicit about the ClickHouse behavior. The destination docs say this warehouse uses ReplacingMergeTree, and the troubleshooting guidance calls out delayed deduped visibility directly. That makes it possible to teach the real table behavior instead of pretending ClickHouse works like every other SQL destination.

Because Skippr also manages tombstones and order tokens automatically, analysts can be taught a simple rule: ordinary queries are fine for settled data, and FINAL matters when you are validating very recent updates.

  • Writes to ClickHouse over the documented HTTP interface.
  • Uses ReplacingMergeTree semantics for final-state CDC reconciliation.
  • Automatically adds _skippr_order_token columns and tombstone tables.
  • Supports point-in-time correctness on recent data with FINAL queries.

What the First Useful Version Looks Like ​

The first useful analyst education is one table and one live example: query immediately after an update, then run the same query with FINAL. That makes the read model tangible instead of theoretical.

If the team cannot tolerate any explanation around recent duplicates, ClickHouse may not be the right analyst-facing warehouse surface. The table semantics are strong, but they are not invisible.