Skippr Docs

Appearance

When ClickHouse Is the Right System Boundary ​

July 2026

ClickHouse is the right system boundary when it already contains the analytical tables you want to move and the HTTP API is a clean, stable extraction surface.

Short Answer ​

ClickHouse is the right system boundary when the useful data product already exists there and you want to extract that product directly instead of rebuilding it from lower-level systems. The source docs are specific about the contract: Skippr reads over the ClickHouse HTTP API, takes a database, and then either a list of tables or one query that overrides table selection.

That makes ClickHouse a strong boundary for analytical rollups, metrics tables, event summaries, or other curated outputs that already have meaning on their own. If product analytics already depends on a metrics table in ClickHouse, reading that table directly is often cleaner than reaching back into the original event store and reproducing the same derivation somewhere else.

Why Teams Struggle with This ​

ClickHouse is a weak boundary when it is only a temporary stop on the way to something more authoritative. The connector is intentionally simple and table-oriented, so it works best when the selected table or query is already a stable contract and not a moving target hidden behind constantly changing SQL.

  • The runner must reach the ClickHouse HTTP URL, so network access to http://...:8123 or the configured endpoint is part of the source decision.
  • The ClickHouse user needs read access to the selected database and tables before any extraction can succeed.
  • Choosing query means that SQL text becomes the contract, because it overrides tables in the connector behavior.
  • If the real need is operational CDC from an upstream database, ClickHouse is usually too far downstream to be the best boundary.

How Skippr Handles It ​

Skippr fits this boundary well because the source surface stays small: url, database, user, password, and either tables or query. That matches the shape of a deliberate analytical handoff instead of pretending ClickHouse is a generic replication engine.

The namespace is explicit as clickhouse.{database}.{table}, which helps teams explain exactly what is being extracted. A handoff such as clickhouse.analytics.daily_revenue is easier to review than a vague promise to "pull reporting data from somewhere in the cluster."

  • Reads from ClickHouse over the documented HTTP API.
  • Supports either selected tables or a custom SQL query.
  • Keeps credentials and database selection explicit in ordinary connector config.
  • Works best when ClickHouse already contains the analytical table shape you want to keep.

What the First Useful Version Looks Like ​

The first useful version is one readable ClickHouse database, one table such as events_rollup or one approved query, and one downstream destination that proves the extracted columns are already meaningful.

If you still expect downstream teams to reinterpret every column or reverse-engineer the SQL that produced the table, ClickHouse is probably not the right boundary yet.