ClickHouse
24.xSummary
Column-oriented OLAP database engineered for sub-second analytical queries on billions of rows, with vectorized execution, aggressive compression, and materialized view support.
Primary Use Case
Real-time analytics on high-volume event data: product analytics, billing aggregations, time-series dashboards, and ad-hoc queries over large datasets that would be prohibitively slow on a row-store database.
Workload Fit
Strengths
Best for
- ·OLAP queries on billions of rows that need sub-second response times
- ·Product analytics aggregations (DAU, retention, funnel analysis)
- ·Real-time dashboards over high-volume event streams
- ·Time-series data where columnar compression and TTL reduce storage costs
Excels when
- ·Queries aggregate over large time windows with GROUP BY on low-cardinality dimensions
- ·Write patterns can be batched (not individual row inserts)
- ·Schema is relatively stable: frequent structural changes are expensive
- ·Query workload is analytical, not transactional
Architectural advantages
- ·Columnar storage enables 10-100x faster analytical scans vs row-store databases
- ·Vectorized execution processes blocks of rows per CPU instruction cycle
- ·Materialized views update incrementally on insert, enabling pre-aggregated fast paths
- ·Native Kafka integration (Kafka engine tables) enables streaming ingestion without ETL
- ·Exceptional analytical scan throughput and compression ratio from columnar, sorted on-disk parts
- ·Columnar pruning by ORDER BY key: a query touching a subset of a table's columns reads only those columns' on-disk part files
When to Avoid
Avoid when
- ·Workload requires ACID transactions or row-level updates (MergeTree mutations are expensive)
- ·Primary access pattern is OLTP key-value lookup: ClickHouse is not designed for point queries
- ·Insert volume is low and analytical queries are simple: PostgreSQL suffices with less complexity
Common misuses
- ·Using ClickHouse as an OLTP database: it is an analytical engine, not a transaction processor
- ·High-frequency single-row inserts causing part fragmentation and merge pressure
- ·Running complex multi-table joins on large datasets: JOIN semantics differ from SQL databases
Consistency & Transactions
Scaling
Read scalability
Queries execute in parallel across all cores on all nodes in a cluster. Distributed tables fan out queries to shards automatically. Columnar storage and vectorized execution make full-table scans orders of magnitude faster than row-oriented databases.
Write scalability
MergeTree engine batches inserts and merges parts asynchronously. High insert throughput is achievable but requires batching: single-row inserts cause excessive part fragmentation.
Failure Behavior
Known failure modes
- ·Too many parts: excessive small insert batches cause part fragmentation and degraded read performance
- ·Replication lag: distributed table replicas can fall behind under heavy insert load
- ·Memory overcommit on complex aggregations: GROUP BY on high-cardinality fields exhausts RAM
- ·Schema migration pain: ClickHouse's ADD COLUMN is fast, but DROP/RENAME are disruptive
Bottlenecks
- ·Memory pressure on high-cardinality GROUP BY aggregations
- ·Part-count explosion from too-frequent small inserts or micro-batches: exceeding the parts-per-partition threshold triggers named 'Too many parts' insert errors until background merges catch up
- ·Distributed query coordination overhead with many small shards
Degradation patterns
- ·Too many active parts causes background merge pressure, degrading insert performance
- ·High-cardinality GROUP BY without ORDER BY optimization causes memory overcommit
- ·Replication lag accumulates under sustained high insert rates
- ·Point-lookup or high-frequency single-row-write workloads degrade steadily as part count grows, since the MergeTree write and merge path is optimized for batched columnar access, not per-row OLTP operations
Recovery considerations
- ·ReplicatedMergeTree tables automatically recover from node failure by fetching missing parts from replicas
- ·Mutations (UPDATE/DELETE) are asynchronous: they do not roll back atomically on failure
- ·Schema changes are not transactional: failed migrations may leave partially applied schemas
Operational Pitfalls
- ·Single-row inserts at high rate: always batch inserts (minimum 1k rows, ideally 100k+)
- ·Using ReplicatedMergeTree without ZooKeeper/ClickHouse Keeper: replication requires coordination layer
- ·Running complex joins: ClickHouse is optimized for aggregations, not OLTP-style joins
- ·Ignoring TTL expressions: unbounded table growth on time-series data exhausts disk
Architecture Guidance
Common topology roles
Migration notes
- ·From PostgreSQL analytics queries: rewrite GROUP BY queries to exploit columnar layout; avoid multi-table JOINs
- ·From BigQuery/Snowflake: ClickHouse is faster for hot data but lacks managed warehouse features (auto-scaling, catalog)
- ·Feeding from Kafka: use ClickHouse Kafka engine tables for streaming ingestion with exactly-once semantics via deduplication
Advisor Guidance
When: scenario has analytics_olap or event_aggregation workload
Batch inserts to ClickHouse in minimum 1k-row batches; single-row inserts cause part fragmentation
When: scenario uses ClickHouse for OLTP workloads
ClickHouse is an OLAP engine: mutations (UPDATE/DELETE) are async and expensive; use PostgreSQL for transactional workloads
When: scenario has time_series data in ClickHouse
Define TTL expressions on time-series tables from day one to prevent unbounded storage growth
Comparison Factors
analytical performance
Very high: sub-second on billions of rows with vectorized columnar execution
operational complexity
Medium: self-hosted requires ZooKeeper/Keeper; managed cloud simplifies ops significantly
insert ergonomics
Medium: requires insert batching discipline; not suited for high-frequency single-row writes
consistency
Eventual: not suitable for transactional workloads requiring read-after-write guarantees
Managed Cloud Options
Enables Patterns
Basis
Strong community documentation; operational characteristics confirmed at multiple production deployments
Sources & Claims
ClickHouse stores table data column-by-column in on-disk parts, physically sorted by the table's declared ORDER BY expression within each part, rather than row-by-row
pendingofficial documentation · ClickHouse documentation: MergeTree table engine, data storage
storage-engine-internals-spine batch 5
The MergeTree engine family is ClickHouse's default and most widely used table engine family, and provides the columnar part storage and background part-merging mechanism
pendingofficial documentation · ClickHouse documentation: MergeTree engine family overview
storage-engine-internals-spine batch 5
ClickHouse UPDATE and DELETE statements are implemented as asynchronous mutations that rewrite whole parts in the background, not as an in-place row-level operation
pendingofficial documentation · ClickHouse documentation: Mutations (ALTER TABLE ... UPDATE/DELETE)
storage-engine-internals-spine batch 5
ClickHouse throws a named 'Too many parts' error and throttles inserts when the number of active parts for a table partition exceeds a configured threshold, a mechanism triggered by frequent small inserts outpacing background part merges
pendingofficial documentation · ClickHouse documentation: MergeTree settings (parts_to_throw_insert, parts_to_delay_insert)
storage-engine-internals-spine batch 5
Learning Modules
Evolution Paths
Related Architecture Knowledge
Outbound: this entity affects
ClickHouse's columnar storage engine, vectorized query execution, and MergeTree family of table engines are specifically designed for analytics-heavy workloads: high-throughput aggregations over billions of rows with sub-second query latency.
Tradeoffs
- ·ClickHouse has limited transaction support: ACID transactions are not a design goal
- ·Point lookups (SELECT * FROM t WHERE id = X) are slower than PostgreSQL: not an OLTP system
- ·INSERT performance is maximized with large batches (1000+ rows): small frequent inserts cause MergeTree pressure
Inbound: affects this entity
Trino is used for federated queries across heterogeneous data sources; ClickHouse provides faster single-store analytics when all data can be consolidated. Organizations often use both: Trino for cross-source joins, ClickHouse for high-frequency dashboard queries.
Full relationship →Used In Architecture Scenarios
Analytics Pipeline
An OLAP-oriented analytics architecture that ingests operational changes from PostgreSQL via WAL-based CDC into Kafka, then routes them to a columnar analytics store (ClickHouse or Snowflake) for product analytics, business intelligence, and operational reporting. The CQRS separation ensures analytical queries never degrade transactional write performance, and materialized views provide pre-aggregated query acceleration for the most expensive analytical patterns.
Financial Ledger
An append-only audit log architecture for capturing system actions: user operations, data access events, configuration changes, and financial operations: with cryptographic integrity chaining, immutable storage, and dual-path query serving. PostgreSQL stores the authoritative append-only event log in time-partitioned tables; ClickHouse serves historical aggregate queries and retention analytics; Kafka streams audit events in real time to SIEM integrations and security dashboards; Redis caches hot audit query results for compliance-facing read paths. No record is ever updated or deleted: only inserts are permitted. Each record includes a hash of the previous record, forming a tamper-evident chain verifiable without external tooling.
Write-Heavy Application
A high-rate device telemetry ingestion architecture designed for millions of devices emitting metrics at 1–60 second intervals. Kafka absorbs device writes as an ingestion buffer, decoupling device-facing ingest endpoints from the storage write path so that downstream storage pressure never propagates back to devices. TimescaleDB provides time-series storage with automatic chunk partitioning by time range, native compression, and continuous aggregate views for rollup queries. ClickHouse serves as the OLAP layer for device fleet analytics queries. Redis caches last-known device state (current readings per device) for real-time alerting queries that must not scan historical storage. Backpressure on the Kafka consumer side prevents storage write throughput from being overwhelmed by burst ingestion events from device reconnect storms.
AI / RAG Application
A low-latency feature serving platform for ML model inference, providing both batch (offline) and real-time (online) feature access with strict training-serving consistency. Redis serves the hot feature cache with p99 latency targets below 5ms for online inference requests; PostgreSQL provides point-in-time feature lookups for offline training jobs with temporal consistency guarantees; Cassandra stores high-cardinality feature entities at write scale beyond PostgreSQL's single-primary ceiling; Kafka streams feature computation events from online feature pipelines to update the cache; Qdrant stores vector features for embedding-based model inputs and similarity lookups; ClickHouse serves feature analytics and drift monitoring across training dataset populations. Feature versioning is first-class: every feature value is tagged with a pipeline_version and computed_at timestamp to support model reproducibility and training-serving skew diagnosis.
Analytics Pipeline
A metrics, logs, and traces ingestion and query platform built to absorb the telemetry output of a production system fleet: including the telemetry volume spikes that accompany the incidents the platform is meant to detect. ClickHouse stores metrics data with automatic time-based rollup via continuous materialized views; TimescaleDB provides complementary time-series storage for high-cardinality alert evaluation; Kafka buffers the ingestion stream against downstream write pressure, decoupling ingest acceptance rate from storage write throughput; Elasticsearch serves log full-text search and structured field filtering; Redis caches dashboard query results and active alert state for sub-100ms alert evaluation latency. The alert engine evaluates threshold and anomaly rules against pre-computed materialized views, not raw data, to bound alert evaluation cost independent of ingestion volume.