Skippr Docs

Appearance

What a Good First ClickHouse Integration Looks Like ​

July 2026

The smallest production ClickHouse setup is one HTTP endpoint, one read-scoped user, and one clear extraction contract: selected tables or one query, not both.

Short Answer ​

A good first ClickHouse integration is one reachable HTTP endpoint, one database, one read-scoped user, and one deliberate extraction boundary. The connector is built for HTTP reads, so the smallest production version is not a cluster-wide export plan. It is a single database such as default, a short tables list like events and metrics, or one custom query when the extracted shape should already be curated.

That boundary matters because ClickHouse can hold both raw tables and already-aggregated analytical tables. If the job is to move stable analytical outputs, one query can be the clean contract. If the job is to copy named tables, keep the query out and let tables stay explicit. The docs are clear that query overrides tables, so the first good production setup chooses one path on purpose instead of pretending both are active.

Why Teams Struggle with This ​

Teams usually make the first ClickHouse integration too wide. They point Skippr at a full database, use a broad account, and only later decide whether the contract is table extraction or SQL output. That creates review and support problems immediately.

  • The ClickHouse HTTP endpoint has to be reachable from the runner, or the setup is not production-shaped yet.
  • A read user needs access to the selected database and tables before any useful extraction can happen.
  • Using both tables thinking and query thinking at once causes confusion because the query overrides table selection.
  • The default local user is acceptable for a laptop test, but it is a weak first production boundary.

How Skippr Handles It ​

Skippr keeps the ClickHouse source narrow: url, database, user, password, and then either tables or query. That is enough to express a real production handoff without inventing another extraction layer.

This is useful when the real decision is about shape, not tooling volume. If clickhouse.default.events is the handoff, keep that visible. If a query that filters or aggregates the table is the handoff, keep that SQL explicit and stable.

  • Reads through the documented ClickHouse HTTP API.
  • Supports a short table allowlist or one custom query.
  • Lets the password stay in an environment variable such as CLICKHOUSE_PASSWORD.
  • Makes the extraction boundary visible as config instead of burying it in an external export job.

What the First Useful Version Looks Like ​

The first useful version is one ClickHouse HTTP URL, one database, one read-only user, and one extraction target such as events or a query that returns the exact fields another system needs. That is enough to prove connectivity, auth, and shape together.

If the team later needs more tables, add them after the first read is already reliable. If the team later needs a curated SQL contract, replace the table list with one query instead of layering both models on top of each other.