Analytics plans
ClickHouse uses its own analytics-* plans, separate from db-* Database plans. Compare topology and capacity first; then confirm current SKU availability and monetary pricing in the Console. The CPU and RAM below are allocated per-instance capacity, not measured consumption by your workload.
Compare SKUs
| SKU | Per-instance capacity | Instances | Included persistent storage |
|---|---|---|---|
analytics-sandbox | 1 vCPU and 2 GiB RAM | 1 | 5 GiB |
analytics-starter | 4 vCPU and 16 GiB RAM | 1 | 10 GiB |
analytics-production | 2 vCPU and 8 GiB RAM | 3 replicas | 25 GiB |
analytics-enterprise | 4 vCPU and 16 GiB RAM | 3 replicas | 50 GiB |
Sandbox and Starter are single-instance options: their names do not imply high availability. Production and Enterprise use three replicas on distinct nodes. Capacity in the table is per instance; included storage is a project-level allowance, not an allowance to multiply by replica count. Check the catalog and creation confirmation for effective availability before ordering.
Understand price and storage
The price shown in the Console and on the pricing page is the total cluster price. For Production and Enterprise, do not multiply it by three: replicas are already part of the SKU. The included storage allowance is persistent. Only provisioned logical capacity above the allowance is billed as additional storage through the logical_gb catalog; that is different from summing queried data bytes or multiplying storage by replicas.
Before confirming, check your selected SKU, configured storage capacity, included allowance, compute price, and applicable additional storage price in the Console. Do not use this capacity table as a monetary price list: BRL prices can change. If configured capacity exceeds the allowance, check the storage breakdown in billing.
Schema and data replication
For new connections, the app database replicates schema changes (DDL). The Zenifra user has ReplicatedMergeTree as the default table engine in that database. On a three-replica plan, a table explicitly declaring MergeTree or another non-replicated engine does not replicate its data just because the project has three instances. Check the engine whenever you adapt a CREATE TABLE statement from another environment. The first-query example intentionally keeps the default engine active.
Plan topology does not replace application testing. Make an authenticated query after project creation and again following relevant changes. Do not infer replication simply because a public port is reachable.
How to choose
- Sandbox: a small starting point for validating queries, with one instance and a smaller storage allowance.
- Starter: more capacity in one instance, without cross-instance data redundancy.
- Production: three replicas with less per-instance capacity than Starter; choose for your workload and replication needs, not by merely adding up vCPUs.
- Enterprise: three replicas with more per-instance capacity and a larger included allowance.
Consider data volume, query patterns, required storage, and availability needs. Do not assume a plan or capacity change is instantaneous or impact-free: check the options currently offered in the Console before modifying an existing project.
Next steps
Getting started with ClickHouse
Create a ClickHouse project in Analytics, store credentials, connect a client, and run CREATE TABLE, INSERT, and SELECT safely.
Connect to ClickHouse
Configure DBeaver over HTTPS/JDBC with ssl=true or clickhouse-client over Native TLS using both project-specific ports shown in the Console.