GreptimeDB vs. ClickHouse

ClickHouse queries fast.
But observability needs more than a query engine.

ClickHouse is a high-performance columnar OLAP database — a general-purpose analytics engine, not built specifically for observability. ClickStack adds OTLP ingestion and ClickHouse has PromQL in private preview, but these are additions on top of the OLAP core. Observability deployments on ClickHouse commonly add a buffering layer, ingestion workers, and transformation steps in front of the database, and metrics, logs, and traces are assembled from separate pieces. GreptimeDB is built for observability on object storage, and runs both near-real-time alerting and long-term analysis on one stack. Click here to read the full report of GreptimeDB vs. ClickHouse in log scenarios.

CHALLENGER

ClickHouse

OLAP engine — observability runs on ClickStack, a separate layer

Time is just another column — storage layout not optimized for observability access patterns
Observability ingestion commonly adds a buffering layer (Kafka/Redis) + workers
PromQL in private preview; ClickStack OTLP is separate from OLAP core
Log storage 2x larger in log benchmark (2.6GB vs 1.3GB)

GREPTIMEDB

GreptimeDB

SQL + PromQL + OTLP + Jaeger — all built in

Timestamp-first storage layout — built for observability from the ground up
Native OTLP endpoint — SDKs write directly, no buffering layer required
Dynamic schema — new span attributes auto-create columns, no migration needed
50% lower log storage with better compression

ClickHouse Stack

4-8 COMPONENTS

Collectors / ETL / Kafka pipeline

ingest + transform

ClickHouse shards + replicas

store + compute

Materialized views + rollups

optimize queries

Separate tooling for observability UX

dashboard + alert adaptation

GreptimeDB

1 DATABASE

Frontend node (stateless, auto-scale)

query + ingest gateway

Datanode (hosts regions, data on object storage)

native object storage

PromQL + SQL support out of the box
Logs, metrics, and traces in one engine
Scale compute and storage independently

Feature comparison

Dimension	GreptimeDB	ClickHouse
Query language	SQL + PromQL (dual, native)	SQL primary, PromQL support in private preview
Data types	Metrics + Logs + Traces in one database	OLAP; observability via ClickStack
PromQL support	Native PromQL query engine	Private preview via the TimeSeries engine (26.9); no native histograms or recording/alerting rules yet
OpenTelemetry	Native OTLP (all signals)	OTLP ingestion via ClickStack (separate from core OLAP engine)
Trace support	Native Jaeger Query API	Via ClickStack
Storage design	Timestamp-first layout, optimized for observability access patterns	Time is another column; general-purpose OLAP layout
Schema evolution	Dynamic — new attributes auto-create columns	JSON or Map columns for new attributes; typed columns need ALTER TABLE
Storage format	Apache Parquet (columnar, compressed)	MergeTree engine family (columnar)
Log storage efficiency	1.3GB (13% compression ratio)	2.6GB (26% compression ratio) — 2x larger
Storage backend	Native object storage (S3, OSS, GCS)	Local disk or S3-backed MergeTree; SharedMergeTree is ClickHouse Cloud only
Ingestion pipeline	SDK → native OTLP endpoint → database (no buffering layer required)	Commonly fronted by a buffering layer (Kafka/Redis) + workers
High-cardinality ingest	Throughput and on-disk size stay nearly flat as series cardinality grows (benchmark)	High-cardinality metrics need careful primary-key and partition modeling
Scaling model	Compute-storage disaggregation; online region migration and repartitioning in open source, automated in Enterprise	Shared-nothing sharding; shard count and key chosen up front, resharding is manual
Replication & HA	One shared copy on object storage; HA via metadata and region leadership	Each replica keeps a full copy (zero-copy replication is experimental); the fully compute-storage-separated engine (SharedMergeTree) is ClickHouse Cloud only
Continuous aggregation	Built-in SQL + Flow streaming engine	Materialized views + aggregating MergeTree
License	Apache 2.0	Apache 2.0
Integration effort	Out-of-the-box observability stack	ClickStack + configuration for observability

Storage comparison from log benchmark tests. Results vary by workload and configuration.

Redirect new ingestion

Docs

Route incoming observability streams to GreptimeDB using compatible protocols while existing ClickHouse pipelines keep running.

30 min

Switch dashboard datasource

Docs

Update Grafana datasource and keep dashboards online with minimal query rewrites.

1 hour

Backfill historical data

Export historical partitions and bulk load into GreptimeDB for unified retention and query.

1-3 days

Retire custom glue

After verification, remove redundant ETL and protocol-conversion components built around ClickHouse.

2 Weeks

Poizon

Staff Engineer

Read the story

We built a cost-effective, real-time monitoring architecture with GreptimeDB. P99 query latency dropped from seconds to milliseconds after replacing multi-stage ETL pipelines with GreptimeDB's unified approach.