Skippr Docs

Appearance

What Access Skippr Needs to Read from ClickHouse ​

June 2026

ClickHouse access is straightforward once the HTTP endpoint, database scope, and read privileges are explicit.

Short Answer ​

Skippr needs a ClickHouse user that can read the selected database and tables, plus network access to the ClickHouse HTTP endpoint. The connector docs are narrow on purpose: you configure url, database, user, password, and either tables or query, so the real access question is whether that user can read the exact objects the HTTP API will expose.

A practical setup is a read-only account on database analytics with permission to read tables such as events and metrics over http://clickhouse.internal:8123. If you switch from tables to query, the SQL query becomes the access boundary because Skippr uses that query instead of table enumeration.

Why Teams Struggle with This ​

Teams usually miss one of two things. They either validate a native or TCP connection and forget the source connector uses HTTP, or they confirm the user can log in but never verify read access on the specific database and tables the pipeline needs.

  • The source connector reads through the ClickHouse HTTP interface, so the URL and port must match that interface, not just any reachable ClickHouse service.
  • The configured user needs read access to the selected database and tables before table extraction can work.
  • A custom query overrides tables, which means the SQL text becomes part of the contract and may touch objects beyond the short table list someone expected.
  • If the password is real but the database name is wrong, the connection can look healthy while the extracted data is empty or misleading.

How Skippr Handles It ​

Skippr keeps the ClickHouse access model easy to audit because the source surface is only the HTTP URL, database, credentials, and extraction scope. That makes access review concrete: can this user read analytics.events through the HTTP API from the machine running Skippr or not.

The docs also push password handling into environment interpolation, which keeps the secret out of skippr.yaml without hiding the operational boundary. When a first run works, you know both the network path and the ClickHouse grants are good enough for the chosen tables or query.

  • Reads ClickHouse through the documented HTTP API.
  • Uses one explicit database context plus either tables or query for source scope.
  • Supports environment-variable password interpolation instead of inline secrets.
  • Produces a readable namespace based on the selected ClickHouse database and tables.

What the First Useful Version Looks Like ​

The first useful version is one database, one read-only user, one reachable HTTP endpoint, and one or two tables whose row counts you can verify against ClickHouse directly.

If you need a wider extract later, add tables deliberately or replace them with a named query after you confirm the query touches only the objects you intend to expose.