Skippr Docs

Appearance

What Access Skippr Needs to Write to ClickHouse ​

June 2026

ClickHouse write access is direct, but the team also has to understand what ReplacingMergeTree means for freshly updated CDC tables.

Short Answer ​

Skippr needs a ClickHouse user that can write to the target database and tables, plus network access to the ClickHouse HTTP endpoint. The destination docs keep it plain: the runtime writes over HTTP, and the user needs write access where Skippr will create or update tables.

That is only half the story for CDC. ClickHouse final-state reconciliation depends on ReplacingMergeTree semantics, with _skippr_order_token columns and tombstone tables added automatically, so the useful write contract is not just permission to insert rows. It is permission to maintain tables whose newest visible state may briefly lag behind a fresh write until merges complete.

Why Teams Struggle with This ​

Teams often confirm the URL and password, run one load, and then get confused when a just-updated CDC table still shows multiple versions. That is not a separate analytics issue. It is part of how this destination behaves and should be treated as part of the write model from day one.

  • The destination uses the ClickHouse HTTP interface, so the URL and port have to be right for write traffic, not just ad hoc reads.
  • The configured user needs write access to the target database and tables.
  • CDC-managed tables use ReplacingMergeTree semantics, so recent duplicates can remain visible until background merges run.
  • Point-in-time reads on fresh data may need FINAL, which is an operational consequence of the destination design, not a workaround for bad permissions.

How Skippr Handles It ​

Skippr keeps the ClickHouse write boundary honest. You configure the normal HTTP connection and the target database, and the platform handles the CDC mechanics with order tokens and tombstones instead of pretending ClickHouse will behave like an in-place row store.

That clarity helps both operators and readers. Operators can verify the user can create and update what Skippr owns, and analysts can be taught exactly when a fresh read may still need FINAL to reflect the newest version immediately.

  • Writes directly to ClickHouse over the documented HTTP API.
  • Needs explicit write access on the chosen database and tables.
  • Uses ReplacingMergeTree-based final-state CDC reconciliation.
  • Automatically creates order-token columns and tombstone tables for managed CDC tables.

What the First Useful Version Looks Like ​

The first useful version is one writable database, one service user, and one CDC-managed table that the team can inspect immediately after inserts and updates.

If consumers will treat delayed merge visibility as broken data, resolve that expectation before you broaden ClickHouse as a warehouse destination.