GreptimeDB vs. ClickHouse

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

ClickHouse is a high-performance columnar OLAP database where time is just another dimension — not the organizing principle of storage. ClickStack adds OTLP ingestion and ClickHouse has early-stage experimental PromQL, but these are additions on top of the OLAP core. Using ClickHouse for observability typically requires buffering middleware, ingestion workers, and transformation pipelines before data reaches the database. 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 time-series access patterns
Observability ingestion typically needs Redis buffering + workers + transform pipelines
Early-stage PromQL (experimental, limited functions); ClickStack OTLP is separate from OLAP core
Log storage 50% larger in [log benchmark](/blogs/2025-04-01-clickhhouse-greptimedb-log-monitoring) (2.6GB vs 1.3GB)

GREPTIMEDB

GreptimeDB

SQL + PromQL + OTLP + Jaeger — all built in

Timestamp-first storage layout — designed for time-series from the ground up
Native OTLP endpoint — SDK writes directly to database, no intermediate queue
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 time-series access	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 middleware)	Typically requires buffering (Redis/Kafka) + ingestion workers
Scaling model	Compute-storage disaggregation, stateless	Shared-nothing sharding, stateful replicas
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.