Skippr Docs

Appearance

How ClickHouse Destination Authentication Works in Skippr ​

June 2026

ClickHouse destination authentication is a direct database-user model over HTTP, and it works best when the write user and the warehouse read expectations are both explicit from the start.

Short Answer ​

ClickHouse destination authentication in Skippr is direct database authentication over the ClickHouse HTTP interface. You configure url, database, user, and password, and the docs recommend keeping the password in an environment variable such as CLICKHOUSE_PASSWORD instead of storing it directly in config.

The important operational detail is that the authenticated user needs write access to the target database and tables, not just the ability to connect. If the warehouse is default on http://localhost:8123, Skippr can authenticate and write there only when that ClickHouse user is allowed to create or update the objects the load depends on.

Why Teams Struggle with This ​

Destination auth in ClickHouse is easy to describe but easy to underspecify. The docs combine endpoint access, write permissions, and CDC behavior into one honest model. The same credentials that succeed on login still have to support the way Skippr writes and reconciles current-state data.

  • Authentication goes to the ClickHouse HTTP endpoint, so the correct URL matters as much as the username and password.
  • The destination user needs write access to the target database and managed tables.
  • Passwords should be supplied through environment interpolation rather than committed into the warehouse block.
  • CDC-managed tables rely on ReplacingMergeTree semantics, so the authenticated warehouse account is being used for a version-converging write model, not instant row replacement.

How Skippr Handles It ​

Skippr stays close to the connector docs here. The destination is a normal ClickHouse user over HTTP, and the CDC contract is explicit: _skippr_order_token columns, tombstone tables, and ReplacingMergeTree-based final-state convergence.

That combination is useful because the auth story and the warehouse behavior line up. A dedicated write user can own raw landing and CDC reconciliation, while downstream readers learn that very fresh data may require FINAL when they need point-in-time correctness.

  • Direct HTTP authentication through url, database, user, and ${CLICKHOUSE_PASSWORD}.
  • A documented requirement that the destination user can write to the target database and tables.
  • CDC support backed by _skippr_order_token columns and tombstone tables.
  • A warehouse model that is explicit about ReplacingMergeTree convergence and FINAL for fresh reads.

What the First Useful Version Looks Like ​

The first useful version is one ClickHouse database and one dedicated write user. That proves connectivity and write privileges before you add more schemas or higher-volume CDC tables.

If analysts will query fresh CDC tables, teach them the read behavior at the same time you provision the warehouse credentials. In ClickHouse, auth and query expectations belong in the same rollout.