OpenObserve
OpenObserve (O2) is an open-source, unified observability platform — logs, metrics, traces, real-user monitoring (RUM), and session replay in one backend — pitched as a self-hostable alternative to observability SaaS like Datadog, Splunk, New Relic, Grafana’s LGTM stack, and the ELK stack. Its hook is cost: the pitch is that the observability bill “costs nearly as much as the application it monitors,” and O2 attacks that at the storage layer. AGPL-3.0, ~19k GitHub stars. Source: a Code Coup / Coding Nexus tech blog (secondary, T3), grounded on vendor facts from openobserve.ai (first-party, self-reported).
Where it sits in the spoke
This is the spoke’s first observability backend product — the place the three signals land and are stored and queried, as opposed to how they’re produced (opentelemetry, the instrumentation standard) or the metrics-only store (prometheus). O2 is OpenTelemetry- native on ingest and speaks both SQL and PromQL on query, so it slots in behind an OTel pipeline as the store the three signals fuse in. It’s the storage/query end of the pillar the wiki had described (metrics/traces/logs) but never had a concrete unified backend for.
The 140× claim — where it comes from
The headline “140× cheaper log storage” is a vendor benchmark against Elasticsearch, and it is an architecture claim, not a discount:
- Columnar Apache Parquet on object storage — data is written as Parquet files to S3, MinIO, GCS, Azure Blob, or local disk, not to attached SSD indices. Object storage is the cheap tier; ES-style inverted indices on hot disk are the expensive one.
- ~40× compression from the columnar layout, which multiplies into the storage-cost gap.
- Apache DataFusion queries the Parquet files directly — no separate indexing/ingest-time structure to pay for. DataFusion is a Rust columnar query engine (the analytical-DB lineage; see cross-spoke note).
So the number is really “columnar-on-cheap-object-storage vs. inverted-index-on-hot-disk,” compounded by compression. Treat the exact multiplier as a self-reported marketing figure; the mechanism (columnar + object storage + Parquet) is the substantive, checkable part. A separate claim puts total cost 8–10× under Datadog by dropping per-host / per-user pricing.
Architecture & scale
- Written in Rust for ingestion/query throughput.
- Deployment: a single binary for POCs and small setups, or a Helm chart for HA / clustered Kubernetes — the same “one binary → clustered” gradient that keeps the ops surface small. A hosted cloud option exists too.
- Reported scale (vendor): “6,000+ organizations,” the largest ingesting >2 PB/day; an internal benchmark of 1 PB queried in ~2 seconds. Self-reported, so T3.
The AI-ops angle
O2 ships an AI Assistant (natural-language → query) and an AI SRE Agent for automated root-cause analysis — a product instance of the aiops thread this spoke tracks: agents reasoning over observability data to investigate incidents (the same shape as google-sre-agentic-ai, here folded into the backend itself). The aiops reliability paradox applies unchanged — an agent doing RCA over your telemetry is only as trustworthy as its own error rate.
Cross-spoke context (runner-up: analytical-databases-wiki)
O2’s engine room — Parquet + object storage + DataFusion vectorized columnar query — is the
analytical-database (OLAP) playbook, the same architecture family as ClickHouse and DuckDB in
analytical-databases-wiki (DataFusion is a close cousin of DuckDB’s embedded-columnar model).
The through-line worth recording: modern observability at scale is an analytical-database problem
in disguise — “store cheaply in columnar object storage, scan fast at query time” is why the log
bill collapses. Routed here (the subject is an observability platform / how you operate telemetry,
squarely this spoke), with the columnar-storage mechanism cross-linked rather than split out.
The sibling that made the opposite call
hyperdx (2026-07-26) reaches the same OLAP conclusion from the other end: rather than build a store, it mounts a search UI on ClickHouse and spends its design budget on the query surface (plain text, filters, regex) instead of the storage layer. O2’s headline problem is the bill; HyperDX’s is the query language. Two open-source Datadog alternatives, one shared premise — telemetry is a columnar-scan problem — and opposite answers to how much of the stack a backend should own.
Related
observability · hyperdx · opentelemetry · prometheus · distributed-tracing · aiops · google-sre-agentic-ai · platform-ops · site-reliability-engineering