Analytics

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

SKUPer-instance capacityInstancesIncluded persistent storage
analytics-sandbox1 vCPU and 2 GiB RAM15 GiB
analytics-starter4 vCPU and 16 GiB RAM110 GiB
analytics-production2 vCPU and 8 GiB RAM3 replicas25 GiB
analytics-enterprise4 vCPU and 16 GiB RAM3 replicas50 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

On this page