OpenObserve vs ClickHouse: One Billion Log Records

A vendor-produced, reproducible benchmark compared ClickHouse with two OpenObserve configurations using Parquet and Vortex formats on identical dedicated nodes, ingesting one billion Kubernetes-style log records totaling 2.2 TB of raw NDJSON and executing 19 indexed, aggregation, and row-fetch queries after ingestion stopped. With matched full-text and secondary indexing, disabled caches, cold-cache controls, and a timestamp-only ClickHouse sort key, OpenObserve configured with a 10 GB compaction target showed geometric-mean query latency advantages of 2.7x for Parquet and 3.4x for Vortex over ClickHouse, while completing the full suite in 3.4x and 4.6x less time respectively and using roughly one-third less disk. The largest reported differences involved high-cardinality counts, common-token counts, and hourly histograms, where OpenObserve used index-based paths, while ClickHouse performed better for a newest-100-row query on a common term due to its timestamp ordering and for a two-term text intersection. Increasing OpenObserve’s file-size target substantially reduced fixed per-file overhead but caused one Parquet-specific regression for a high-cardinality row fetch; Vortex avoided that regression and was notably faster for row retrieval, though it used slightly more storage. The authors note that the test does not measure independent ingestion throughput, time-range pruning, concurrent workloads, or fully tuned deployments, and argue that the public repository allows others to inspect and rerun the methodology.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.