Agentic analytics starts with query-ready data: the write-side cost of Snowflake vs. ClickHouse

Summary

Agentic analytics workflows introduce bursts of concurrent, low-latency analytical queries over continuously ingested data. Analytical query efficiency relies on columnar storage and chunk-level pruning, which require contiguous, sorted data to avoid full-table scans. Rather than evaluating warehouses solely at query runtime, this benchmark compares the write-side cost of maintaining query-ready data in ClickHouse and Snowflake during continuous ingestion at approximately one million rows per second. Snowflake relies on post-write clustering to organize data, whereas ClickHouse constructs sorted layouts on the write path and refines them via background merges. Across 100B, 200B, and 300B row checkpoints on the ClickBench dataset, ClickHouse achieved a query-ready layout at 22 times lower cost and delivered 28 times better write-side cost-performance.

Context

Agentic workloads execute high-concurrency, low-latency query sequences over freshly arriving data. Evaluating analytical databases purely by query execution ignores the compute cost and architectural overhead required to keep streaming data ordered and query-ready for pruning before queries begin.

Approach / What changed

A benchmark measured the cost of continuously ingesting roughly one million rows per second into ClickHouse and Snowflake across 100B, 200B, and 300B row checkpoints using the ClickBench dataset, comparing Snowflake's post-write clustering against ClickHouse's write-path sorting and background part merges.

Takeaways

• ClickHouse achieved a query-ready data layout at 22 times lower cost and delivered 28 times better write-side cost-performance than Snowflake across 100B, 200B, and 300B row checkpoints.
• Snowflake stores 5x to 15x more compressed data than ClickHouse on identical sorting keys using the ClickBench dataset, increasing storage costs, object storage latency exposure, and downstream query I/O.
• ClickHouse preserves pruning granularity at the granule level (approximately 10 MB uncompressed row blocks) driven by its sparse primary index even after background merges consolidate datasets.

Related reading