Skippr Docs

Appearance

What Network or Staging Access ClickHouse Needs ​

July 2026

ClickHouse destination access is a direct HTTP write path to one database, with no separate staging bucket in the documented connector.

Short Answer ​

ClickHouse needs a reachable HTTP endpoint and a user that can write to the target database and tables. The destination docs keep the connector centered on url, database, user, and password, which means the useful load path is a direct HTTP write path such as http://localhost:8123, not a separate bucket staging workflow hidden somewhere else.

That distinction matters when teams compare destinations loosely. If the target database is default, the runner has to reach the ClickHouse HTTP listener from its own network and authenticate as a user with write access there. When CDC is involved, the destination still uses that same path, then relies on ReplacingMergeTree behavior, _skippr_order_token, and tombstone tables to converge on final state after writes land.

Why Teams Struggle with This ​

ClickHouse destinations usually fail for straightforward reasons: the HTTP endpoint is not reachable from the runner, the database user can log in but not write, or people expect deduped current state to appear instantly without understanding how recent merges show up.

  • The runner must reach the ClickHouse HTTP endpoint, not just another service attached to the same host.
  • The ClickHouse user needs write access to the target database and tables.
  • CDC correctness depends on ReplacingMergeTree convergence, so fresh reads can still need FINAL.
  • A successful connection test does not prove the database named in config is the one the user can actually write.

How Skippr Handles It ​

Skippr makes the ClickHouse destination path easy to inspect because there is no extra staging layer in the documented connector. One URL, one database, one write user, then the destination tables. That makes infrastructure conversations shorter and operational ownership clearer.

It also keeps CDC expectations grounded in the docs. The warehouse path is direct, but the final-state read model still depends on ClickHouse merge behavior, which is why it is worth validating one recently updated table and teaching consumers when FINAL matters.

  • Writes directly over the ClickHouse HTTP interface.
  • Targets one explicit database with one explicit user.
  • Creates order-token and tombstone tables automatically for CDC-managed tables.
  • Uses the documented ReplacingMergeTree final-state model instead of inventing a second reconciliation layer.

What the First Useful Version Looks Like ​

The first useful version is one ClickHouse database, one small table, and one query check right after a write so the team understands what immediate visibility looks like.

If the HTTP endpoint or write grants are still uncertain, resolve those first. ClickHouse gets much easier once the direct write path is unambiguous.