Skippr Docs

Appearance

How to Configure ClickHouse as a Source Connector ​

May 2026

ClickHouse source setup is mostly about getting the HTTP endpoint, credentials, and extraction scope right before the first read.

Short Answer ​

Configure ClickHouse as a source by setting source.kind to clickhouse_source, then supplying the HTTP url, database, user, and password. For a standard local setup that is often http://localhost:8123, database default, user default, and a password loaded from an environment variable such as CLICKHOUSE_PASSWORD.

For the first run, keep the extraction scope narrow with either tables or a single query. Reading events and metrics from one database is easier to validate than starting with a broad wildcard because you can confirm the namespace, schema, and row counts against a known slice of ClickHouse data.

Why Teams Struggle with This ​

The ClickHouse source connector is simple, but it assumes the HTTP interface is the one you can reach. Teams sometimes verify the native port is open and then forget Skippr is using the HTTP API, or they pass a database name the user can authenticate against but not actually read.

  • The connector talks to the ClickHouse HTTP endpoint, so the url and port must match that interface, not just any reachable ClickHouse service.
  • The user needs read access on the selected database and tables.
  • A password belongs in an environment variable such as CLICKHOUSE_PASSWORD, not directly in skippr.yaml.
  • You should choose either a table list or a custom query so the first extract has a clear boundary.

How Skippr Handles It ​

Skippr exposes the exact ClickHouse fields the docs describe instead of hiding them behind a generic SQL abstraction. That makes the configuration predictable: HTTP URL, database, credentials, then either tables or query depending on whether you want full-table extraction or a shaped result set.

A good first setup is easy to test operationally. If the connector is correct, Skippr can authenticate, enumerate the requested source objects, and ingest from a stable namespace like clickhouse.default.events without you having to hand-build a driver config.

  • Direct support for the ClickHouse HTTP API.
  • Read scope controlled by either tables or query.
  • Password handling through environment interpolation such as ${CLICKHOUSE_PASSWORD}.
  • Namespaces that stay readable when you trace source tables through the pipeline.

What the First Useful Version Looks Like ​

Keep the first source run focused on one or two tables so you can validate the schema Skippr infers from ClickHouse before widening the extract.

If the environment uses custom networking or TLS termination, confirm the runner can reach the exact HTTP URL that ClickHouse exposes to clients.