Estimating resources

Resource estimation guidance for Managed ClickStack deployments

The following provides a model for estimating the compute and storage resources required for a ClickStack deployment based on your expected ingest volume. The values produced are estimates only and should be used as an initial baseline - they are not a prescriptive answer. Actual requirements depend on query complexity, concurrency, retention policies, and variance in ingestion throughput. Always monitor resource usage and scale as needed.

:::important All figures are based on uncompressed raw ingest Every number on this page - throughput (MB/s, TB/month), CPU sizing, and storage - is expressed in terms of uncompressed raw ingest volume, i.e. the size of the data as produced by your applications and sent to the OpenTelemetry collector before any compression is applied.

This is the figure you should estimate from your existing logs, traces, and metrics pipelines. Storage figures in the table below already have the assumed 10x compression ratio applied to this raw volume. :::

When deploying ClickStack, provision compute to cover two independent workloads: ingest and query.

Workload	Estimated resources
Ingest	1 vCPU per 10 MB/s of sustained ingest throughput
Query	1 vCPU per 1 QPS and per 10 MB/s of sustained ingest throughput

Isolation of Queries vs Ingest

In most self-managed deployments, ingest and query share the same nodes. In this case, use the Total CPUs as your baseline. Isolated scaling - where ingest and query compute are provisioned independently - is supported in ClickHouse Cloud through separate compute pools aka Warehouses.

Assumptions

• A 10x compression ratio for storage - typically conservative for logs and traces.
• Query SLAs of a P50 of 1.5 seconds and a P99 of 5 seconds.
• We assume most queries occur over recent data, following a log-normal distribution that peaks at around one hour and tails out to around six hours. Users may wish to provision dedicated compute to query older data. In ClickHouse Cloud this can be idle (thus not incuring costs) when not in use.
• While query compute can be scaled independently of ingest compute, it remains intrinsically linked to ingest volume. We assume as ingest increases, data density grows, resulting in larger scan volumes at query time and consequently higher query compute requirements.

The following table provides example sizings based on increasing ingest throughput in megabytes per second, alongside the corresponding data volumes in terabytes per month. This assumes a sustained average of 1 QPS from ClickStack across all query types (search, dashboards, alerting).

MB/s	TB/month	Ingest CPUs	Query CPUs	Total CPUs	Total Storage (per month) (GB)
10	25.92	1	3	4	2,592
20	51.84	2	6	8	5,184
50	129.6	5	15	20	12,960
100	259.2	10	30	40	25,920
200	518.4	20	60	80	51,840
500	1,296	50	150	200	129,600
1000	2,592	100	300	400	259,200

Refining sizing assumptions for your environment

The model assumes a sustained average of 1 QPS from ClickStack, aggregating all query types including search, dashboards, and alerting.

For higher query volumes, scale CPU requirements linearly by multiplying CPU requirements by the target QPS. For example, a deployment ingesting at 100 MB/s with a target of 9 QPS would require 90 query CPUs (10 × 9) rather than the baseline 10, giving a revised total of 100 CPUs (10 ingest + 90 query).

Storage estimates assume a conservative 10x compression ratio. In practice, logs, traces, and metrics often achieve higher compression. We recommend testing on a sample of data to establish your compression ratio and storage requirements in advance of production. To compute the required storage for longer retention, multiply the storage per month by the number of months required to retain.

This assumes a relatively balanced query distribution. Workloads skewed toward heavier historical or archival queries may have significantly different compute requirements, and should be validated through load testing. We plan to introduce a more flexible sizing model that allows extrapolation of query compute based on varying query distribution patterns.

Worked example

Requirements: 1.5 PB/month ingest, 5 QPS, 3-month retention.

Converting to MB/s

The sizing model is expressed in MB/s. Converting 1.5 PB/month (1,500 TB) to a sustained throughput:

• 1,500 TB = 1,500,000,000 MB
• Seconds per month (30 days): 30 × 24 × 60 × 60 = 2,592,000
• MB/s = 1,500,000,000 ÷ 2,592,000 ≈ 579 MB/s

Ingest compute

At 1 vCPU per 10 MB/s of sustained ingest:

579 ÷ 10 = ~58 vCPUs for ingest

Query compute

Query compute scales with both ingest throughput and QPS. At 5 QPS:

(579 ÷ 10) × 5 = 58 × 5 = 290 vCPUs for query

Storage

At 579 MB/s sustained over 30 days, raw ingest equals 1,500 TB/month. Applying the assumed 10x compression ratio:

• Compressed per month: 1,500 TB ÷ 10 = 150 TB/month
• For 3-month retention: 150 TB × 3 = 450 TB total

Summary

Resource	Value
Ingest compute	58 vCPUs
Query compute	290 vCPUs
Total compute	348 vCPUs
Storage per month (compressed)	150 TB
Storage for 3-month retention	450 TB

Isolating observability workloads

If you’re adding ClickStack to an existing ClickHouse Cloud service that already supports other workloads, such as real-time application analytics, isolating observability traffic is strongly recommended.

Use Managed Warehouses to create a child service dedicated to ClickStack. This allows you to:

• Isolate ingest and query load from existing applications
• Scale observability workloads independently
• Prevent observability queries from impacting production analytics
• Share the same underlying datasets across services when needed

This approach ensures your existing workloads remain unaffected while allowing ClickStack to scale independently as observability data grows.

For larger deployments or custom sizing guidance, please contact support for a more precise estimate.