Skippr Docs

Appearance

How ClickHouse Source Authentication Works in Skippr ​

June 2026

ClickHouse source authentication in Skippr is straightforward HTTP database auth, but it only works cleanly when the user, database, and readable tables are all explicit.

Short Answer ​

ClickHouse source authentication in Skippr is plain database authentication over the ClickHouse HTTP API. You configure url, database, user, and password, and the clean production version usually keeps the password in an environment variable such as CLICKHOUSE_PASSWORD instead of storing it in skippr.yaml.

That means the useful auth question is not just "can these credentials log in?" but "can this user read the exact data we named?" A source set to http://localhost:8123, database analytics, and table events is only healthy when the same ClickHouse user can reach that HTTP endpoint and read analytics.events without relying on a wider personal account.

Why Teams Struggle with This ​

Teams often call this a simple username-and-password connector, which is true but incomplete. The docs tie authentication to the HTTP interface and to read access on the selected database and tables, so a valid login can still be the wrong auth model if it points at the wrong database or has more privilege than the pipeline needs.

  • Skippr authenticates against the ClickHouse HTTP URL, not a separate native driver surface, so the reachable endpoint is part of the auth contract.
  • The source user needs read access to the selected database and tables before extraction can do anything useful.
  • A custom query overrides tables, which changes what permissions and source scope the authenticated user actually needs.
  • The docs recommend environment interpolation for password, which keeps secret rotation out of the checked-in config.

How Skippr Handles It ​

Skippr keeps the ClickHouse auth model narrow and reviewable. You can look at the source block and immediately see which endpoint, database, username, and secret source the connector depends on, instead of chasing credentials through an opaque setup wizard.

That makes a first production setup easier to teach. A dedicated read user, an explicit database, and a short table list create a stable source boundary. If authentication fails later, you can check one of four concrete things: URL, database, user, or password.

  • Direct ClickHouse HTTP authentication through url, database, user, and password.
  • Password handling through ${CLICKHOUSE_PASSWORD} or another environment-backed secret.
  • Documented requirement that the source user can read the selected database and tables.
  • A source namespace of clickhouse.{database}.{table} that keeps the authenticated scope readable downstream.

What the First Useful Version Looks Like ​

The first useful version is one ClickHouse HTTP endpoint, one dedicated read user, and one or two known tables. That proves the auth boundary without mixing endpoint, scope, and query complexity together.

If you later switch from table reads to a custom query, treat that as a source-contract change, not just a credential reuse. The authenticated user is now authorizing a different extraction shape.