Skippr Docs

Appearance

When to Use ClickHouse as a Source Connector ​

May 2026

The ClickHouse source connector is best when ClickHouse already contains the data product you want to move, and the HTTP API is the easiest extraction surface.

Short Answer ​

Use the ClickHouse source connector when ClickHouse is already the place where useful analytical tables exist and you want to move those rows into another destination without adding a separate export tool. It is especially practical when the HTTP interface is reachable, the source user can read the required database, and you already know which tables or query output should be extracted.

A common fit is an internal analytics cluster that already computes event rollups or metrics tables. Instead of rebuilding those transformations somewhere else first, Skippr can read the specific tables or run one query over the ClickHouse HTTP API and hand those results to a downstream warehouse or file destination.

Why Teams Struggle with This ​

The tradeoff is that this connector is purposefully simple. It reads through the HTTP API, not through a specialized change stream, so the quality of the integration depends on clear table selection, stable query logic, and straightforward network access.

  • You need a ClickHouse user with read access to the target database and tables before extraction will work at all.
  • The HTTP endpoint has to be reachable from the machine running Skippr, which is often the first real blocker in managed deployments.
  • If the real need is row-by-row operational CDC, ClickHouse as a source is usually the wrong shape because the connector is about table or query extraction.
  • Choosing between tables and query matters because a custom SQL query overrides table selection and becomes part of the contract.

How Skippr Handles It ​

Skippr keeps the source surface compact: URL, database, user, password, and either tables or a query. That makes it a good connector for moving analytical outputs that are already curated in ClickHouse instead of re-ingesting lower-level data from somewhere else.

Because the namespace is explicit as clickhouse.{database}.{table}, it is also easier to explain downstream what was extracted and from where.

  • Reads ClickHouse data over the HTTP API.
  • Supports extracting selected tables or a custom SQL query.
  • Uses standard user and password authentication with environment-variable-friendly config.
  • Fits handoff patterns where ClickHouse already contains the table shape you want.

What the First Useful Version Looks Like ​

The first useful version is one database, one readable table such as events or metrics, and a single destination that proves the HTTP extraction path and column shape are correct.

It is a bad fit when the team really needs upstream change capture semantics, cannot expose the ClickHouse HTTP endpoint, or does not yet trust the source tables enough to treat them as an integration boundary.