Skip to main content
ClickHouse is a columnar database built for reading one column across billions of rows, which is the shape of analytics, event and metrics workloads. Siblings reach the instance at its service name. It is not reachable from outside the cluster.

​
Creating an instance

Select New → Database, then ClickHouse. The form asks for a name, a version, a database and user, the compute allocation and a disk size.The database and user default to randomised names derived from the service rather than a guessable default.
latest is not a valid version. A managed database has to be reproducible, so the tag is always pinned. The memory floor is the smallest allocation the engine runs on. If you configure less, the deploy fails rather than silently raising it.
ClickHouse needs at least 2 GiB, and 4 GiB is a better starting point. Its caches size themselves from the machine rather than the container, so a small allocation turns into an out-of-memory loop that reads as a broken image. slipway writes a config overlay scaled to the allocation you pick and re-renders it on every deploy, so it stays correct after a resize.

​
Two ports, one instance

ClickHouse answers on two protocols and slipway declares both. This is one instance with two ports, not two services. A sibling reaches either directly:
slipway.yaml
${service.analytics.url} resolves to the native form, because that is what clickhouse-connect, clickhouse-go and the JDBC driver parse. Build the HTTP form from ${service.analytics.host} as above. Readiness is gated on 8123. The native port accepts connections slightly before the server can answer, so HTTP is the honest signal.

​
Authentication

Each instance is provisioned with a generated password for its primary user, stored as the project secret <SERVICE>_PASSWORD. Additional users are managed on the service’s Credentials tab and are created with SQL CREATE USER, so they live in the instance’s own data directory on the disk and survive restarts.

​
External access

Not available. ClickHouse instances are reachable from siblings in their project. To query one from your machine, open the service’s Shell and run clickhouse-client in the pod.

​
Backups

The disk mounts at /var/lib/clickhouse and is backed up on a schedule, restorable in place from the service’s Disks tab. Retention depends on your plan. See Disks.

​
Metrics

The service overview shows CPU, memory and active connections, sampled every 30 seconds. The Metrics tab charts those over a window you choose, plus disk usage against the volume’s size.

​
Pricing

Compute is metered by the second against the allocation a service is configured with, so a service that sleeps costs nothing while it is asleep. Disk, backups and object storage are metered on what is provisioned or held, whether or not the service is running. ClickHouse is priced on the allocation you configure. The disk is billed on its provisioned size. There is no per-query, per-row or per-scanned-byte charge.