Capacity planner

Sluicio runs the whole stack — ClickHouse, Postgres, the ingest + API services, and the frontend — on infrastructure you control. Because retention is bounded, your telemetry volume plateaus rather than growing forever, so a surprisingly small box goes a long way. Use the calculator to get a starting point, then read how it gets there below.

Your telemetry

Logs

per month per day

Metrics data points per day active series × scrape interval

points/day

@ 15s 30s 60s · recommended 120s 5 min

Traces spans per day requests/day × spans each

spans/day

×

Retention (days)

Peak factor (×avg)

Enterprise required. Retention beyond 14 days is a Sluicio Enterprise entitlement (retention_long) — it needs a license key, even self-hosted.

Recommended box

2

vCPU

4

GB RAM

20

GB SSD

Breakdown

Ingest (avg / peak)—

Rows retained—

Logs on disk—

Metrics on disk—

Traces on disk—

Data footprint—

Copy spec

Assumptions (editable)

Bytes/log (compressed)

Bytes/metric point

Bytes/span

ClickHouse overhead ×

Disk headroom ×

Defaults assume ZSTD compression on tables sorted by service name. Storage = rows × bytes/row × overhead; disk adds a 20 GB base for OS, images, and Postgres. RAM / CPU / cost are tiered heuristics, not a benchmark.

How it estimates

The numbers come from three signals × your retention window:

• Storage is the defensible part. Each signal’s retained rows (rate × retention days) are multiplied by a compressed bytes-per-row estimate, then by a ClickHouse overhead factor for indexes, marks, and merge headroom. ClickHouse stores telemetry sorted by service name and compresses it with ZSTD, so repeated dimensions shrink dramatically — logs land around 300 bytes/row, metric points around 40, spans around 500. A 20 GB base is added for the OS, container images, and the Postgres control plane.
• RAM is tiered off the retained row count (ClickHouse is the memory-hungry component), with a bump when sustained ingest is high. The stateless Go services and Postgres add a small fixed floor.
• CPU is tiered off peak ingest rate (average × your peak factor).

All of these are editable under Assumptions — if you know your real compression ratio or row sizes, dial them in.

The two levers that matter most

1. Traces usually dominate. One request produces many spans, and spans are the heaviest row. Logs and metrics alone keep you on a small single box; adding tracing is what pushes you up a tier. If you trace, that’s the input to get right.
2. “Metrics” means points, not series. 30,000 data points per day is tiny. But 30,000 active series scraped every 15 seconds is ~173 million points per day — four orders of magnitude more. Use the active series × scrape interval mode if you’re scraping Prometheus-style endpoints, and the storage estimate will reflect reality.

Scrape every 60s, not every 15s

For integration monitoring you rarely need 15-second metric resolution — queue depth, error rate and throughput are just as actionable at 60s, and often at 120s for slow-moving values. Metric storage scales inversely with the interval, so moving from 15s to 60s stores 4× fewer points for the same series. The calculator defaults to 60s and flags it when you pick something more aggressive.

Single box vs. split

Below roughly 2 billion retained rows / 16 GB RAM / 10k events per second, everything runs comfortably on one VM via the bundled docker-compose deployment. Past that, the move is to give ClickHouse its own node (or a managed instance), put Postgres on a managed service, and keep the stateless services on the app box.

Backups

Whatever the size, the state worth protecting is Postgres — it holds your orgs, users, integrations, and alert rules. Back it up nightly (pg_dump). ClickHouse telemetry is effectively disposable: it ages out at your retention window anyway, so a backup there is optional.

Note

The CPU, RAM, and cost figures are tiered heuristics meant as a sensible starting point, not a benchmark for your exact workload. Validate against real ingest before committing to production hardware — and if you can share your trace volume and whether metrics are points or series, the estimate gets a lot sharper.