Introduction

ClickHouse is a strong OLAP engine. On general analytical workloads — BI queries, ad-hoc aggregations over wide tables, data-warehouse-style columnar scans — it is hard to beat. That same engine is increasingly used as a backend for observability through ClickStack, and teams running large log and trace pipelines often end up on ClickHouse for the cost envelope alone.

The trade-off shows up at the seams. ClickHouse treats time as just another column, not as the organizing principle of storage. PromQL support in the ClickHouse ecosystem is early-stage and limited to basic functions like rate, delta, and increase. OTLP ingestion flows through ClickStack — a separate layer on top of the OLAP core — which in practice means Redis or Kafka buffering, ingestion workers, and transform pipelines before data lands in the database.

GreptimeDB takes a different approach. Metrics, logs, traces, and wide events are stored in the same engine, with timestamp-first storage layout, native OTLP ingestion, full PromQL compatibility, and a Jaeger Query API — all built in rather than assembled. GreptimeDB reached v1.0 GA in April 2026. This article walks through where it is a direct alternative to ClickHouse for observability workloads, and where ClickHouse still wins.

OLAP Engine vs. Observability Engine

ClickHouse is a general-purpose columnar OLAP database. Its MergeTree storage engine is excellent at sequential scans over wide columns. Time is a first-class dimension but not the storage organizer; partitioning by date is conventional but optional.

GreptimeDB's storage layout is timestamp-first. Every table has a TIME INDEX, and SST files are sorted and partitioned along that axis. This is the shape observability queries take — "last 15 minutes of errors for service X", "p99 latency over the past hour grouped by endpoint" — and the physical layout matches the access pattern instead of working against it.

The schema model is also different. ClickHouse is schema-on-write with fixed columns; adding a new span attribute means an ALTER TABLE or a migration. GreptimeDB treats incoming OTLP spans or wide events as dynamic: new attributes auto-create columns, and the schema evolves with the data.

Native OTLP, PromQL, and Jaeger vs. ClickStack

For observability ingestion, the two stacks look quite different:

• ClickHouse + ClickStack: OpenTelemetry collector → Redis/Kafka buffer → ingestion workers → transformation pipeline → ClickHouse. PromQL via experimental layer. Traces via ClickStack's Jaeger adapter. Logs via a separate schema.
• GreptimeDB: OTLP SDK writes directly to GreptimeDB's native OTLP endpoint. PromQL is a first-class query interface, not an add-on. Jaeger Query API is exposed natively.

Fewer moving parts means fewer failure modes, and — relevant for cost — no intermediate queue paying to stage the same bytes twice.

Log Benchmarks: Write Throughput, Compression, Query Latency

In a head-to-head benchmark on structured and unstructured logs (GreptimeDB v0.12 vs. ClickHouse 24.9, 10 GB raw data), GreptimeDB came out ahead on most of the numbers that matter for observability workloads:

Metric	GreptimeDB	ClickHouse
Write TPS (structured)	185,535	166,667
Write TPS (unstructured)	159,502	136,612
COUNT query (structured)	6 ms	46 ms
Keyword search (structured)	22.8 ms	52 ms
Persisted size (structured, 10 GB raw)	1.3 GB	2.6 GB
Compression ratio	13–33%	26–51%
Memory (structured workload)	408 MB	611 MB

Roughly half the log storage footprint for the same dataset, at comparable or better query latency.

ClickHouse's own JSONBench on 1 billion documents adds another data point: GreptimeDB ranked first on Cold Run and fourth on Hot Run, validated on the benchmark ClickHouse itself maintains.

For S3-backed deployments, GreptimeDB on object storage shows roughly 1–2% performance loss versus local disk. ClickHouse supports S3 but primarily as a cold storage tier rather than primary, which changes the cost model at scale.

Operational Complexity: Four to Eight Components vs. Two

A typical ClickHouse observability stack has:

1. Collectors and ETL (OTel Collector, Vector, Fluent Bit).
2. A Kafka or Redis buffer for backpressure.
3. ClickHouse shards and replicas (stateful, with ZooKeeper/ClickHouse Keeper coordination).
4. Materialized views and aggregating MergeTree tables for query optimization.
5. Separate tooling or adapters for observability UX — Grafana, dashboards, alert routing.

That is 4–8 operational surfaces, each with its own version, scaling story, and failure mode.

GreptimeDB's architecture is simpler: a stateless frontend (query and ingest gateway), stateless datanodes, and native object storage. Compute and storage scale independently. No sidecar, no Kafka buffer between SDK and database, no separate query-optimization tier.

Dynamic Schema for OTLP Spans

Trace data is messy. Applications instrument new attributes constantly, different services emit overlapping but non-identical fields, and the span shape drifts over time. In ClickHouse, each new attribute is an ALTER TABLE or a schema migration. Teams either pre-define a rigid schema (losing visibility into new fields) or push everything into a Map(String, String) column (giving up type information and query efficiency).

GreptimeDB treats this as a first-class case: incoming OTLP attributes auto-create columns with the right type, and span payloads do not need a DBA in the loop. Combined with the v1.0 Flat SST storage format — which improved write throughput roughly 4× and some query latencies up to 10× on TSBS with 2M series — high-cardinality trace and wide-event workloads behave closer to how they should.

Object Storage First vs. Local Disk Primary

ClickHouse was designed around local disk. S3 is supported as a cold-storage tier, and cloud-native ClickHouse offerings have added more object-storage integration, but the core engine assumes fast local storage for hot data. At observability scale — terabytes per day retained for weeks — this drives infrastructure cost.

GreptimeDB stores immutable Parquet blocks directly in Amazon S3, Google Cloud Storage, Azure Blob, or MinIO. At current AWS list prices, S3 Standard (~$0.023/GB/mo) sits roughly 3–5× below provisioned SSD EBS (gp3 ~$0.08/GB/mo, io2 ~$0.125/GB/mo); Glacier Deep Archive drops another order of magnitude for cold data. A multi-tier cache keeps recent data on NVMe for low-latency reads. Combined with columnar compression and compute-storage disaggregation, GreptimeDB's OSS product page leads with up to 50× total cost reduction for observability workloads.

Case: Poizon

Poizon built a real-time monitoring architecture around GreptimeDB after evaluating alternatives. In the words of their staff engineer: "P99 query latency dropped from seconds to milliseconds after replacing multi-stage ETL pipelines with GreptimeDB's unified approach." The ETL-pipeline reduction is exactly the simplification ClickHouse-plus-ClickStack setups tend to accumulate over time.

When ClickHouse Still Wins

This is an alternative-for-observability comparison, not a "ClickHouse is bad" argument. ClickHouse remains the better choice for:

• General-purpose OLAP and BI workloads not dominated by time-series access patterns.
• Large data-warehouse queries where scans across hundreds of columns and years of history matter more than latency-sensitive PromQL.
• Existing ClickHouse skill sets on teams that are already deeply invested and whose query patterns are fundamentally analytical, not observability-shaped.

If your workload is genuinely 50/50 BI-and-observability, running both is reasonable. The case for GreptimeDB as an alternative gets strongest when observability is the primary workload and you find yourself building an ingestion pipeline, a PromQL shim, a Jaeger adapter, and a tiered-storage layer on top of ClickHouse to make it fit.

Conclusion

GreptimeDB is a direct alternative to ClickHouse for observability workloads: native OTLP and PromQL, timestamp-first storage, dynamic schema for traces, object-storage-first architecture, and roughly 2× smaller log footprint at comparable or better write throughput. For workloads where ClickHouse needs ClickStack plus a buffering layer plus materialized views plus adapters, GreptimeDB ships the same capabilities as one engine.

See the full GreptimeDB vs. ClickHouse comparison for the feature table and migration path, or deploy GreptimeDB on Kubernetes to test it against your current ClickHouse observability workload.

---

About Greptime

GreptimeDB is an open-source, cloud-native database purpose-built for real-time observability. Built in Rust and optimized for cloud-native environments, it provides unified storage and processing for metrics, logs, and traces — delivering sub-second insights from edge to cloud at any scale.

• GreptimeDB OSS – The open-sourced database for small to medium-scale observability and IoT use cases, ideal for personal projects or dev/test environments.

• GreptimeDB Enterprise – A robust observability database with enhanced security, high availability, and enterprise-grade support.

We're open to contributors — get started with issues labeled good first issue and connect with our community.

GitHub | Website | Docs

Slack | Twitter | LinkedIn