ClickHouse vs Elasticsearch: Architecture for 1M Events per Second

At 1M events/sec, the bottleneck is the write path. ClickHouse is built for insert-heavy workloads and merges in the background.

Elasticsearch indexes every field for search. That is powerful, but it creates write amplification that becomes expensive at scale.

For analytics, you want fast ingest and predictable compression, not full-text inverted indexes on every property.

Analytics teams live on high-cardinality dimensions like path, referrer domain, and campaign. ClickHouse keeps these dimensions queryable with dictionary encoding and sparse index scanning.

Elasticsearch can handle cardinality, but it trades memory and heap pressure for it. That means more nodes, more tuning, and more operational work.

ClickHouse keeps scan speed predictable. This is crucial for dashboards and automated anomaly detection that fire every few minutes.

Below is a minimal schema tuned for event analytics. It stays compact and avoids user-level PII while preserving aggregation flexibility.

CREATE TABLE anonview_events (
  timestamp DateTime,
  site_id UUID,
  event_type LowCardinality(String),
  session_hash FixedString(64),
  path String,
  referrer_domain String,
  metadata String
)
ENGINE = MergeTree
PARTITION BY toDate(timestamp)
ORDER BY (site_id, timestamp, event_type);

• Choose ClickHouse when queries are analytical, time-based, and aggregate-heavy.
• Choose Elasticsearch when search relevance, full-text, or fuzzy matching is the primary workload.
• Use both only if you can justify double ingestion and extra operational overhead.