OpenObserve as a ClickHouse Alternative
ClickHouse is a fast open source columnar database with excellent compression and aggregation performance. It is a strong storage engine, but it is a database, not an observability platform. Teams that pick ClickHouse for logs, metrics, and traces then design schemas, run an ingestion pipeline, attach a visualization layer, and build alerting around it. OpenObserve ships all of that as one product on the same columnar foundations. This page compares the two approaches.
Why Teams Choose OpenObserve Over a ClickHouse-Based Stack
You assemble the platform yourself
With ClickHouse, the database is the starting point. A working observability stack also needs:
- Table schemas and partitioning keys designed per signal type, with cardinality and ORDER BY choices made up front
- An ingestion pipeline (OpenTelemetry Collector, Vector, or custom writers) that batches inserts to match how MergeTree tables ingest efficiently
- A visualization layer such as Grafana or the HyperDX UI from ClickStack, ClickHouse's packaged observability stack
- An alerting system, since alert evaluation and notification live outside the database
- Retention management through table TTL clauses per table
Each piece works, and each piece is yours to integrate, upgrade, and debug. OpenObserve includes ingestion endpoints, storage, a query engine, dashboards, alerting, and pipelines in a single Rust binary or Helm chart. Streams accept data without upfront schema design.
Operational surface area
A replicated ClickHouse cluster needs ClickHouse Keeper (or ZooKeeper) for coordination, shard and replica topology defined in cluster configuration, and capacity planning for stateful nodes. Resharding an existing cluster is a manual data-movement exercise. Deletes and updates run as background mutations that rewrite data parts.
OpenObserve nodes are stateless. Data durability comes from object storage, so scaling out means adding ingester or querier replicas. There is no coordination service to run and no resharding.
Storage tied to cluster disks
Self-hosted ClickHouse stores data on the disks of stateful nodes. S3-backed disks and tiered storage exist, but full separation of compute and storage (SharedMergeTree) is available in ClickHouse Cloud. On your own hardware, retention growth means disk growth on database hosts, replicated across replicas.
OpenObserve stores raw events as Apache Parquet in your bucket: S3, GCS, Azure Blob, MinIO, or local disk. Long retention costs object-storage rates, and any tool that reads Parquet can read your telemetry data.
Metrics without PromQL
ClickHouse queries are written in its SQL dialect, including metric queries built in Grafana. Existing Prometheus dashboards and recording or alerting rules must be rewritten as SQL.
OpenObserve runs PromQL natively for metrics alongside SQL for logs and traces. Prometheus Remote Write is a supported ingestion path, and existing PromQL dashboards and alert expressions carry over.
Feature Comparison
| Feature | ClickHouse | OpenObserve |
|---|---|---|
| Product type | Columnar OLAP database | Observability platform |
| Open source | Yes (Apache 2.0) | Yes |
| Logs | Via your schema and pipeline | Yes, built in |
| Metrics | Via your schema and pipeline | Yes, full Prometheus / PromQL compatibility |
| Traces | Via your schema and pipeline | Yes, first-class OpenTelemetry support |
| Visualization | External (Grafana, HyperDX) | Built-in UI and dashboards |
| Alerts | External (Grafana or custom) | Yes, SQL/PromQL-based alerting |
| Ingest transforms | Materialized views, custom pipeline code | Pipelines with Vector Remap Language (VRL) |
| Query language | SQL (ClickHouse dialect) | SQL + PromQL |
| Schema | Designed and maintained per table | Schema inferred per stream |
| Retention | TTL clauses per table | Retention setting per stream |
| Storage model | Stateful nodes with attached disks; S3 disks optional | Object storage (S3 / GCS / Azure Blob / MinIO / local disk) |
| Replication | ClickHouse Keeper / ZooKeeper coordination | None needed; durability from object storage |
| IAM & SSO | Database users, roles, and row policies | SAML, OIDC, LDAP, role-based access |
| Deployment | Self-host or ClickHouse Cloud | Self-host or OpenObserve Cloud |
Architectural Differences
| Layer | ClickHouse-based stack | OpenObserve |
|---|---|---|
| Ingest agents | OpenTelemetry Collector, Vector, or custom writers with batched inserts | OpenTelemetry Collector, Fluent Bit, Vector, Filebeat (via _bulk), JSON over HTTP |
| Wire protocol | ClickHouse native protocol or HTTP interface | OTLP, Prometheus Remote Write, Loki Push API, JSON over HTTP, Elasticsearch _bulk |
| Storage | MergeTree parts on node disks, replicated across replicas | Apache Parquet on object storage |
| Query | ClickHouse SQL against stateful servers | SQL/PromQL against stateless queriers reading Parquet |
| Visualization | Grafana or HyperDX, run separately | OpenObserve UI (built-in) |
| Coordination | ClickHouse Keeper / ZooKeeper | None |
Cost Profile
Both systems are open source with no per-GB license fee, so the comparison is infrastructure and engineering time.
A self-hosted ClickHouse stack pays for stateful database nodes sized for the full retained dataset, multiplied by the replica count, plus the Grafana and alerting components beside it. The larger line item is engineering: schema evolution, cluster upgrades, Keeper operations, and pipeline maintenance are ongoing platform work.
OpenObserve cost is dominated by ingest compute + object storage + query compute. Storage is not replicated by the application because object stores provide durability, and queriers are sized for query load rather than the total dataset. The platform work (schemas, dashboards-to-database glue, alert plumbing) is not yours to build.
What Stays the Same
Moving from a ClickHouse-based stack to OpenObserve does not require re-instrumenting applications:
- OpenTelemetry instrumentation carries over unchanged. Repoint the OTel Collector's exporter from the ClickHouse exporter to OpenObserve's OTLP endpoint.
- Vector and Fluent Bit pipelines need an output swap, not a rewrite.
- SQL skills transfer. OpenObserve queries logs and traces with SQL, so the query style your team knows still applies. Rewrite ClickHouse-specific functions in standard SQL.
Where a ClickHouse Stack Fits
ClickHouse remains a good choice when telemetry is one workload inside a broader analytics platform you already run, or when you need a general-purpose warehouse for product analytics and BI alongside logs. The trade is engineering ownership of the platform layer. If the goal is observability itself, OpenObserve delivers the assembled system.
Migration Shape
A typical move runs in three steps:
- Stand up OpenObserve in parallel. Add it as a second output on your existing OTel Collector, Vector, or Fluent Bit pipeline. No application changes.
- Rebuild dashboards and alerts. Translate ClickHouse SQL panels to OpenObserve SQL and move Prometheus-style alerting to OpenObserve's native PromQL alerts. The OpenObserve AI Assistant helps convert queries.
- Cut over. Validate query results and retention side by side, shift alert routing, then decommission the ClickHouse observability tables or cluster.
Teams already on OpenTelemetry can start ingesting into OpenObserve within hours; the parallel-run window is driven by dashboard and alert count.
Need Help?
- Join our Community Slack
- Or Contact support