ClickHouse Cloud: how do I choose between Basic vs Scale vs Enterprise for our workload?

Most teams evaluating ClickHouse Cloud end up with the same question: should we start on Basic, jump straight to Scale, or do we actually need Enterprise for our workload? The right answer depends far less on “how big is our data” and far more on your latency SLOs, concurrency patterns, operational constraints, and who is on call when something breaks.

Quick Answer: Use Basic for single-team apps, early-stage products, and well-bounded workloads that can live in a single service. Choose Scale once you need multi-service architectures, higher and spikier concurrency, stronger isolation between workloads, or more control over scaling and backup behavior. Move to Enterprise when you have strict security/compliance requirements, multi-region and cross-account governance needs, or you want ClickHouse to architect and operate mission‑critical analytics, observability, or AI backends with contractual SLAs.

Why This Matters

Picking the wrong ClickHouse Cloud tier usually shows up three months later as either surprise costs (because you over-provisioned) or operational friction (because you tried to run “petabyte + hundreds of QPS + many teams” on a single shared service). Matching Basic vs Scale vs Enterprise to your actual workload lets you:

Keep millisecond query latency even as data volume and concurrency grow.
Control blast radius between services and teams instead of running one “kitchen sink” cluster.
Get the right level of governance, observability, and support without overpaying for features you don’t use.

Key Benefits:

Predictable performance: Align tier to query patterns (real-time dashboards, logs/metrics, ML & GenAI) so you maintain sub-second reads at billions‑of‑rows scale.
Operational safety: Use the right isolation and management features so you don’t hit failure modes like “too many parts,” runaway costs, or noisy-neighbor workloads.
Governance & trust: Match security, compliance, and support expectations—especially important when ClickHouse becomes the backend for revenue-critical products or AI systems.

Core Concepts & Key Points

Concept	Definition	Why it's important
Service	A logical ClickHouse Cloud deployment (compute + storage + configuration) that runs one or more databases.	Most sizing and tier decisions are really “how many services do we need, and how isolated should they be?”
Workload class	The dominant usage pattern: real-time analytics, observability (logs/metrics/traces), BI, or ML/GenAI (including vector search).	Different classes stress ClickHouse differently—e.g., observability pushes ingest and parts/merges, BI pushes concurrency and heavy aggregates.
SLO & blast radius	SLO is the latency/availability you promise; blast radius is how widely a failure or regression spreads.	Scale and Enterprise tiers exist to keep critical workloads isolated so a bad query or ingest spike in one doesn’t take down everything.

How It Works (Step-by-Step)

At a practical level, choosing between Basic, Scale, and Enterprise is a workload classification exercise. I recommend you walk through it in this order:

Characterize your workload
Map to a tier based on constraints
Validate with a small experiment

1. Characterize your workload

Start with four questions:

What are we storing and querying?
- Mostly real-time product analytics / event streams?
- High-cardinality logs/metrics/traces?
- Mixed BI dashboards with heavy aggregates?
- ML & GenAI features: vector embeddings, retrieval, feature stores?
What are our SLOs?
- Query latency: do we need P95 < 200 ms, < 1 s, or “a few seconds is fine”?
- Ingest: do we push tens of thousands to millions of events per second, or more modest batched loads?
Who uses it, and how many teams?
- Single product team?
- Multiple internal teams, each shipping their own pipelines and dashboards?
- External customers (multi-tenant SaaS), where noisy-neighbor risk is real?
What are our constraints?
- Compliance (PII, data residency, auditability).
- Support expectations (best-effort vs strict SLAs).
- Governance: who can create services, change configs, or manage backups?

Keep notes. The same raw data size (say 20 TB) can fit comfortably on Basic or absolutely require Scale/Enterprise depending on concurrency and organizational complexity.

2. Map to a tier based on constraints

Below is a practical heuristic that matches how I’ve seen teams land in the right place.

When Basic fits best

Basic is optimized for:

Single-service deployments.
Clear SLOs with a small number of stakeholders.
Teams that want ClickHouse’s performance and cost profile without complex multi-tenant governance.

It’s a strong fit when:

Workload size & pattern
- Data is GBs to low tens of TBs to start, growing over time.
- Concurrency is moderate: e.g., dozens of concurrent queries, not hundreds, and most queries are sub-second aggregates or simple filters.
- Ingest is high but bounded and well-behaved—e.g., event tracking, product analytics, or a single app’s logs/metrics where you can batch inserts to 1,000–100,000 rows per insert to keep MergeTree healthy.
Use case
- Single app or product analytics store.
- Early-stage logs/metrics backends before you onboard all teams.
- A single vector search + metadata store backing one or two AI features (RAG, recommendation, personalization).
Operations & governance
- One “owner team” runs the pipeline and dashboards.
- You’re OK starting with a simpler service layout and evolving later.
- You want managed operations (autoscaling, separation of storage/compute, backups in the console) without complex org-level policies.

Choose Basic when your main concern is:

“We need a blazing-fast, low-ops data warehouse for this product or team, and we can live with one service as the unit of isolation.”

When Scale is the right move

Scale is about multi-service architectures, larger workloads, and higher concurrency, while staying developer-friendly. Use it when:

Workload size & pattern
- Data is tens to hundreds of TBs, or you know you’ll reach that quickly (logs/metrics/observability, large SaaS analytics).
- You expect high concurrency: hundreds of dashboard users, multiple BI tools, or several microservices hitting ClickHouse concurrently.
- You have multiple workload types on the same data: e.g., real-time dashboards + offline analytics + vector search queries.
Use case
- ClickHouse becomes your system of record for a business unit or a major product line.
- You’re building a speed layer in front of a slower data warehouse, serving both internal analysts and production traffic.
- You’re consolidating observability (logs + metrics + traces) into ClickHouse using something like ClickStack, with several teams pushing data and querying it.
- You’re backing agentic or GenAI systems that depend on millisecond retrieval over billions of events, embeddings, or features.
Operations & governance
- You need multiple services with different scaling profiles: e.g., one optimized for heavy ingest, another for BI, another for vector workloads.
- You care about blast radius: a misconfigured ETL or a runaway query shouldn’t impact everything else.
- You want more control over backup schedules, scaling behaviors, and potentially cross-environment patterns (dev/stage/prod) as distinct services.

Choose Scale when your concern is:

“ClickHouse is central to our architecture; we have multiple workloads and teams, and we need isolation and headroom without hand-rolling our own cluster management.”

When Enterprise is justified

Enterprise is for organizations where ClickHouse underpins mission-critical, regulated, or multi-region workloads and where you need deep platform integration and guarantees.

Workload size & pattern
- Data is hundreds of TBs to petabytes, or you’re onboarding multiple such workloads.
- High, sustained QPS: many hundreds to thousands of queries per second, plus large ingestion pipelines across teams.
- Multiple high-SLO workloads share the platform: e.g., customer-facing analytics, internal observability, and AI/ML features.
Use case
- You’re a SaaS vendor providing real-time analytics, observability, or AI tooling to many customers, and ClickHouse is the shared backend.
- You’re in regulated industries (financial services, healthcare, telecom) where compliance, data residency, and audit requirements drive architecture.
- You’re building company-wide analytics or AI infrastructure: one internal platform team manages ClickHouse, and dozens of product teams use it.
Operations & governance
- You require enterprise-grade security, SSO/SAML integrations, fine-grained access control, auditability, and possibly private networking guarantees.
- You want formal SLAs, direct access to ClickHouse engineers, and co-architecture support for schema design, workload partitioning, and cost optimization.
- You need features around multi-region, DR, and advanced org-level controls that go beyond single-project management.

Choose Enterprise when your concern is:

“ClickHouse will be as critical as our primary databases and message buses—we need tight security, compliance, SLAs, and shared-tenant governance across many teams and regions.”

3. Validate with a small experiment

Once you’ve guessed a tier, validate with a controlled pilot:

Start with one representative workload
- Example: one microservice’s logs, one AI feature’s vector store, or one business unit’s main analytics dashboard.

Instrument reality with system tables

Sample latencies and resource use via system.query_log:

SELECT
    query_kind,
    quantile(0.95)(query_duration_ms) AS p95_ms,
    avg(rows_read) AS avg_rows_read,
    avg(memory_usage) AS avg_bytes
FROM system.query_log
WHERE event_time >= now() - INTERVAL 15 MINUTE
  AND type = 'QueryFinish'
GROUP BY query_kind
ORDER BY p95_ms DESC;

Watch ingest health via system.parts and system.merges to ensure you’re not creating too many tiny parts:

SELECT
    table,
    count() AS parts,
    quantile(0.5)(rows) AS p50_rows_per_part,
    quantile(0.9)(rows) AS p90_rows_per_part
FROM system.parts
WHERE active
GROUP BY table
ORDER BY parts DESC;

Stress the likely bottleneck
- For analytics: increase concurrency (more dashboard sessions, BI queries).
- For observability: spike ingest from a subset of services.
- For AI/vector workloads: test worst-case retrieval patterns on large embedding sets.
Compare against your SLOs
- If P95 latency and ingest stability look good with headroom, your chosen tier is probably right.
- If you’re hitting performance or management limits, you likely need to graduate to Scale or Enterprise to split workloads into multiple services or tighten governance.

Common Mistakes to Avoid

Treating Basic as a “forever multi-tenant home” for everything:
Running diverse, high-growth workloads from many teams in a single Basic service seems convenient until one pipeline goes rogue and you’re debugging “too many parts,” slow merges, and unpredictable latencies. Use Basic for bounded scopes; use Scale or Enterprise for multi-tenant consolidation.
Jumping to Enterprise just for “future proofing”:
Over-buying can slow you down with premature process and governance. If you don’t yet have strict compliance, multiple business units, or mission-critical revenue workloads on ClickHouse, start with Basic or Scale and let the needs pull you into Enterprise.

Real-World Example

A product-led SaaS company started with Basic to power in-app analytics: a single ClickHouse Cloud service storing a few TBs of event data, with sub-second dashboards for PMs and customers. As adoption grew, they:

Added more event types and onboarded a new AI feature that used embeddings and vector search against the same event stream.
Introduced a company-wide BI layer hitting the same service with heavier, long-running queries.
Began ingesting logs from part of their infrastructure to support debugging and performance investigations.

Within a few months, they hit classic symptoms:

Query latencies spiked during ingest bursts.
A small subset of exploratory BI queries created pressure on memory and CPU.
Teams wanted different retention policies and backup schedules.

They moved to Scale and split into three services:

Real-time analytics service: tight SLOs, aggressive autoscaling, tuned for interactive dashboards.
BI & reporting service: separate compute tuned for heavier aggregates and less strict latency.
AI & observability service: schema and settings optimized for vector search and log-style ingestion.

This instantly reduced blast radius: a BI query gone wrong no longer impacted customer-facing dashboards, and they could tune ingestion and retention differently per service. As ClickHouse became the backbone for customer-facing analytics, they later evaluated Enterprise to add tighter security controls and a formal SLA.

Pro Tip: When you see more than two distinct workload profiles (e.g., real-time dashboards, heavy BI, and logs/metrics) competing on one service, that’s your signal to move to Scale or Enterprise and break them into multiple services with tight, per-workload tuning.

Summary

Choosing between Basic, Scale, and Enterprise in ClickHouse Cloud is about matching the tier to:

Workload class & scale: analytics, observability, BI, ML & GenAI—plus data size and concurrency.
Operational complexity: how many teams and workloads share the platform, and how much isolation you need.
Governance & risk: security, compliance, blast radius, and support expectations.

Use Basic as your starting point for single-team or single-product workloads that need blazing-fast analytics without complex governance. Move to Scale when ClickHouse becomes a shared platform across multiple workloads and services, and isolate those workloads into separate services with their own scaling profiles. Adopt Enterprise when ClickHouse is mission-critical infrastructure with strict compliance, multi-region needs, and formal SLAs.

Next Step

Get Started

Answers you can trust, from Codeables