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 early-stage experimental PromQL, 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
Early-stage PromQL (experimental, limited functions); ClickStack OTLP is separate from OLAP core
Log storage 50% 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 (compute, stateless)

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, early-stage experimental PromQL support
Data types	Metrics + Logs + Traces in one database	OLAP; observability via ClickStack
PromQL support	Native PromQL query engine	Experimental (limited to basic functions like rate/delta/increase)
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	Requires ALTER TABLE or schema migration
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 primary, S3 via cold storage
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; regions auto-rebalance and repartition as data grows	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.