SigNoz OpenTelemetry Observability: ClickHouseCalc MergeTree Sizing for Logs & Spans
In our deterministic ClickHouseCalc model, SigNoz stores OpenTelemetry logs, distributed traces, and histograms inside MergeTree tables where Map(LowCardinality(String), String) tags paired with ZSTD(3) pack 1,480-byte raw spans at ~10.5x columnar compression.
ClickHouseCalc Compression, RAM & TCO Schedule for signoz-otel-observability
| Ingestion Scale | Raw Volume | MergeTree NVMe Disk | Node RAM & vCPU | Modeled TCO Delta (2026-11-12) |
|---|---|---|---|---|
| 50M Spans/Day (30d · 74 GB/d) | 2.22 TB Raw | 260 GB NVMe (ZSTD-3 + 22% Buffer) | 16 GB RAM / 4 vCPU | ~$790/mo Datadog vs $10.49/mo Hostinger KVM 4 |
| 250M Spans/Day (90d · 370 GB/d) | 33.3 TB Raw | 4.05 TB NVMe/RAID | 64 GB RAM / 16 vCPU | ~$5,480/mo Datadog vs $79.00/mo InterServer Ryzen |
| 1B Spans/Day (90d · 1.48 TB/d) | 133.2 TB Raw | 16.1 TB RAID Array | 128 GB RAM / 24 vCPU | ~$21,600/mo Datadog vs $119–$149/mo Dedicated Node |
ClickHouseCalc SigNoz OTel MergeTree DDL & Bloom Skip-Index Blueprint
CREATE TABLE signoz_logs.logs_v2
(
timestamp UInt64 CODEC(DoubleDelta, LZ4),
observed_timestamp UInt64 CODEC(DoubleDelta, LZ4),
trace_id FixedString(32) CODEC(ZSTD(1)),
span_id String CODEC(ZSTD(1)),
severity_text LowCardinality(String) CODEC(ZSTD(1)),
body String CODEC(ZSTD(3)),
resources_string Map(LowCardinality(String), String) CODEC(ZSTD(3)),
attributes_string Map(LowCardinality(String), String) CODEC(ZSTD(3)),
INDEX body_idx lower(body) TYPE ngrambf_v1(4, 60000, 5, 0) GRANULARITY 1,
INDEX trace_idx trace_id TYPE bloom_filter(0.001) GRANULARITY 1
)
ENGINE = MergeTree
PARTITION BY toDate(timestamp / 1000000000)
ORDER BY (severity_text, toUnixTimestamp(toStartOfMinute(fromUnixTimestamp64Nano(timestamp))))
TTL toDateTime(timestamp / 1000000000) + INTERVAL 90 DAY DELETE
SETTINGS index_granularity = 8192;
ClickHouseCalc MergeTree Production Checklist for signoz-otel-observability
- Batch OTel Collector exports (`batch: send_batch_size: 10000, timeout: 5s`) so ClickHouse writes wider parts instead of raising `Too many parts (300)` insert errors.
- Cap `<max_server_memory_usage_to_ram_ratio>0.75</max_server_memory_usage_to_ram_ratio>` in `/etc/clickhouse-server/config.d/memory.xml` so the co-located OTel Collector retains safe OS memory.
- Separate TTL retention (`15 DAY` for verbose debug spans, `90 DAY` for HTTP 5xx & audit logs) via MergeTree row TTL clauses.
ClickHouseCalc Engineering FAQ: signoz-otel-observability
- How does ClickHouseCalc size SigNoz primary.idx RAM compared to an Elasticsearch ELK stack at 100M logs/day?
-
Elasticsearch maintains per-token inverted posting lists in a 31 GB JVM heap, whereas our ClickHouseCalc MergeTree formula loads only 1 sparse index mark per 8,192 rows into memory—keeping index working sets compact.
- Why does ClickHouseCalc recommend ZSTD(3) over LZ4 for SigNoz OpenTelemetry log bodies?
-
In our ClickHouseCalc codec model, applying ZSTD(3) on `body` and `attributes_string` deduplicates repetitive stack traces and Kubernetes pod labels ~42% tighter than LZ4 with modest merge CPU overhead.