Skippr Docs

Appearance

What to Check Before Ingesting from ClickHouse ​

April 2026

Your first ClickHouse ingestion usually succeeds when the HTTP endpoint, database scope, and table selection are verified before you point Skippr at production data.

Short Answer ​

Before ingesting from ClickHouse, confirm five things: the HTTP URL is reachable, the database name is correct, the user can read the target tables, the password is injected through an environment variable instead of committed config, and you know whether you are ingesting specific tables or a custom query. Skippr reads ClickHouse through the HTTP API, so a working SQL console session is not enough if the HTTP interface is disabled or listening on a different port.

A common first run is url: http://localhost:8123, database: default, and tables: [events]. That only works if the ClickHouse user can read default.events over HTTP. If the real workload lives in analytics.events and the runner can only reach a private hostname, you want to fix that before ingestion starts rather than debug an empty or failed pipeline afterward.

Why Teams Struggle with This ​

ClickHouse looks simple because the config surface is short, but short configs make wrong assumptions easier to hide. Teams often verify the database in one client, then forget that Skippr needs the HTTP URL, the right database, and explicit read access for the exact tables it will extract.

  • The connector uses the ClickHouse HTTP interface, so a reachable native TCP setup does not guarantee ingestion will work.
  • If database is wrong, the same table name can resolve to the wrong schema or no table at all.
  • If you specify tables, the user needs read access on each one; if you specify query, that query becomes the extraction contract.
  • Password handling matters on day one because the docs recommend environment variable interpolation instead of putting secrets in skippr.yaml.

How Skippr Handles It ​

Skippr keeps the setup explicit. You can point it at a ClickHouse HTTP URL, bind it to one database, and either list the tables to ingest or replace table selection with a custom query. That is useful when the first useful version of the pipeline is intentionally narrow, such as one events table instead of an entire analytics database.

Because the connector contract is small, a disciplined preflight review goes a long way. If the endpoint answers over HTTP, the selected database is correct, and the ClickHouse user can read what you named, the first ingestion tends to be uneventful.

  • HTTP-based ClickHouse source configuration with url, database, user, and optional password.
  • Target selection through either tables or a custom query.
  • Environment-variable-friendly password configuration for cleaner secret handling.
  • A clear namespace pattern of clickhouse.{database}.{table} when you need to reason about extracted objects.

What the First Useful Version Looks Like ​

The first useful ClickHouse pipeline is usually one database plus one or two known-good tables, not a broad sweep across everything the cluster exposes.

If you want a fast preflight test, verify the exact HTTP host, database, and table names you plan to put in config and make sure the runner reaches that endpoint from the same network where Skippr will run.