Appearance

How to Configure ClickHouse as a Warehouse Destination ​

May 2026

ClickHouse destination setup starts with the HTTP endpoint and credentials, then gets better once the team understands how fresh writes converge.

Short Answer ​

Configure ClickHouse as a warehouse destination by setting warehouse.kind to clickhouse, then providing the HTTP url, database, user, and password. The docs default to http://localhost:8123 and user default, but production setups usually swap in a dedicated write user and pull the password from CLICKHOUSE_PASSWORD.

The clean first setup is a database the connector can write into and a team expectation that recently updated CDC tables may still be converging. Skippr uses ClickHouse over HTTP and, for CDC-managed tables, relies on ReplacingMergeTree semantics plus _skippr_order_token tracking, so query users should know when FINAL is appropriate on fresh data.

Why Teams Struggle with This ​

Most ClickHouse destination mistakes come from treating it like an in-place row store. The connection may be correct and the writes may succeed, but the warehouse still needs merge time before deduplicated final state is fully visible on every query.

  • The connector writes through the HTTP interface, so the URL and reachable port matter as much as the credentials.
  • The ClickHouse user needs write access to the target database and tables.
  • Passwords should be injected from an environment variable rather than committed in config.
  • Teams querying freshly updated CDC tables need to understand ReplacingMergeTree convergence and when FINAL is worth the cost.

How Skippr Handles It ​

Skippr keeps the ClickHouse destination honest about how it works. You configure a normal HTTP connection, and the platform handles load operations while preserving the CDC final-state contract with order tokens and tombstones for managed tables.

That means the first successful setup is more than a connectivity check. You should be able to load data into ClickHouse, inspect the raw target tables, and explain why a just-written table may need FINAL when someone wants the newest version immediately.

  • Warehouse configuration centered on the ClickHouse HTTP URL and database credentials.
  • CDC support that automatically adds _skippr_order_token columns and tombstone tables.
  • Operational guidance that matches ReplacingMergeTree behavior instead of pretending deduplication is instantaneous.
  • A practical first-run model for teams already using ClickHouse for analytics.

What the First Useful Version Looks Like ​

Start with a small destination database and confirm the write user can create and update the tables Skippr manages.

If query consumers need exact point-in-time reads on very fresh CDC data, teach them the difference between merged state and immediate post-write visibility before rolling the warehouse out broadly.