Skippr Docs

Appearance

Common ClickHouse Source Setup Mistakes ​

May 2026

ClickHouse source setup usually goes wrong when teams point Skippr at the wrong interface, over-assume defaults, or leave table selection implicit.

Short Answer ​

The biggest ClickHouse source mistakes are using the wrong endpoint, treating the database name as optional, and assuming table discovery will infer what you meant. Skippr reads ClickHouse over the HTTP API, so the source should be configured with the HTTP URL, database, user, and either an explicit table list or a query that intentionally overrides table-based extraction.

That distinction matters fast. A team might point Skippr at localhost:9000 because that is the port they use elsewhere, but the connector docs are built around the HTTP interface at a URL like http://localhost:8123. Another common miss is leaving database vague in an environment where default exists but the real tables live somewhere else, which produces a clean connection and the wrong data.

Why Teams Struggle with This ​

ClickHouse can look forgiving in local development because the default user and default database often work on a laptop. Production setups expose the mistakes: HTTP access may be behind a different hostname, passwords should be injected with environment variables, and tables versus query changes the extraction shape completely.

  • Using a native or TCP-oriented ClickHouse endpoint instead of the documented HTTP URL causes connection confusion.
  • Leaving database on the wrong default can produce valid but misleading extracts from the wrong schema context.
  • Teams often specify both table expectations and a broad custom query without realizing the query overrides tables.
  • Storing the password directly in skippr.yaml instead of using environment interpolation creates an avoidable secret-management problem.

How Skippr Handles It ​

Skippr keeps the ClickHouse source surface compact and explicit: url, database, user, password, tables, and optional query. That makes it obvious whether you are ingesting concrete tables or a shaped result set, which is more useful than a connector that silently guesses.

The docs also stay honest about the operational boundary. The ClickHouse user needs read access to the selected database and tables, and the runner must be able to reach the HTTP endpoint. Skippr does not blur those requirements into a generic connectivity message.

  • HTTP-based ClickHouse source configuration with clear url and database fields.
  • Explicit choice between table extraction and custom SQL query extraction.
  • Support for environment-variable password interpolation instead of hardcoded secrets.
  • A namespace pattern that makes the selected database and table scope easy to reason about.

What the First Useful Version Looks Like ​

A solid first pass uses a dedicated read-only user, one confirmed HTTP endpoint, and a short table list that proves the connector is pointed at the intended database.

Once that works, decide whether you want table-native ingestion or a curated query result, because that decision affects how people interpret the raw landing tables later.