Analytics plans

ClickHouse uses its own Analytics plans (identified by analytics-*), separate from Database plans. Compare topology and capacity first; then confirm current plan availability and pricing in the Console. The CPU and RAM below are allocated per-instance capacity, not measured consumption by your workload.

Compare plans

Sandbox and Starter are single-instance options: their names do not imply high availability. Production and Enterprise use three replicas on distinct servers. 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.

Metrics by plan

• Sandbox: queries work, but the operational and storage metrics panels and endpoints are locked.
• Starter, Production, and Enterprise: the Console displays measured CPU and RAM usage, current connections, running queries, uptime, and physical disk occupancy for each instance.

These are on-demand snapshots, not a history or an alerting service. If there is no recent reading yet, CPU/RAM display unavailable, not zero. The CPU/RAM capacities in the table above are allocated; panel values are measured instance usage. Physical disk occupancy is per instance and is not contracted logical capacity, included storage allowance, or billable usage; do not add the bytes of three replicas as if they were distinct data.

Understand price and storage

The price shown in the Console and on the pricing page is the total project price. For Production and Enterprise, do not multiply it by three: replicas are already included in the plan. The included storage allowance is persistent. Only provisioned logical capacity above the allowance is billed as additional storage; that is different from summing queried data bytes or multiplying storage by replicas.

Before confirming, check your selected plan, 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. See Changing plans before modifying an existing project.

Changing plans

In the Console, Analytics databases only show analytics-* plans. The plan defines the instances (Sandbox and Starter: 1 instance; Production and Enterprise: 3 replicas), so the instances field is read-only: to change instances, change the plan. You need the project.plan.update permission on the project.

• Upgrading to Production or Enterprise: two new instances receive a copy of the data, and the Console confirms when the change finishes.
• Downgrading to Sandbox or Starter: one instance remains with all the data of replicated tables. Before removing the others, Zenifra confirms that instance has everything.
• Tables without replication block the downgrade: tables created with an engine without replication (for example, MergeTree) that hold data prevent the change, because the data on each instance would differ. Move that data to tables with the default engine and try again.
• How long it takes: the change may finish immediately or continue for a few minutes. In that case, the Console shows a notice and refreshes on its own. If the change cannot be completed, the database stays on the previous plan and the Console shows that.
• Billing: changes when the change completes. Contracted storage stays the same, and what exceeds the new plan's allowance is billed separately.

Next steps

• Create a project and run your first query.
• Configure client protocols.
• Learn about passwords, availability, and troubleshooting.