OpenObserve: a single-binary observability platform with Parquet storage on S3

What OpenObserve replaces, and for whom

OpenObserve targets the team that already runs Elasticsearch or pays a per-host observability bill and wants the storage line item to shrink. The README frames it as a cost-effective alternative to Datadog, Splunk, and Elasticsearch, and claims storage costs up to 140x lower than Elasticsearch through Parquet columnar storage and an S3-native design. It is built for logs, metrics, traces, Real User Monitoring, pipelines, and AI/LLM observability in one product rather than four. The intended user is an infrastructure or platform engineer comfortable running a container, pointing it at a bucket, and querying with SQL or PromQL. It is not aimed at someone who wants to click through a hosted signup with no operational surface at all, although the project does offer a cloud tier.

How the storage and query model actually differ

The design decision that shapes everything else is where bytes live. Instead of an inverted index held on local disks and replicated across nodes, OpenObserve writes columnar Parquet files and treats object storage as the primary home. That is why the README can promise a single binary deployment with no cluster setup, and why the cost comparison is framed against Elasticsearch rather than against another log store.

The query layer follows from that choice. Logs and traces are queried with SQL, metrics with SQL or PromQL, so there is no proprietary query language to learn. The repository is a Rust workspace: the root Cargo.toml defines the openobserve package at version 0.93.0 and a set of Cargo features including enterprise, cloud, vectorscan, mimalloc, jemalloc, profiling and tokio-console. Those features tell you the open source build and the commercial build share a codebase, and that the enterprise capability is compiled in through feature flags rather than shipped as a separate product.

Ingest is OpenTelemetry-native according to the README, which matters more than it sounds: it means the collection path is the standard one, and the project is not asking you to install a proprietary agent before you can send anything.

Installing OpenObserve with Docker and logging in

The README gives a Docker command as the fastest self-hosted path. It mounts a local data directory, publishes port 5080, and sets the root credentials through environment variables. The image referenced is public.ecr.aws/zinclabs/openobserve:latest.

docker run -d \
      --name openobserve \
      -v $PWD/data:/data \
      -p 5080:5080 \
      -e ZO_ROOT_USER_EMAIL="[email protected]" \
      -e ZO_ROOT_USER_PASSWORD="Complexpass#123" \
      public.ecr.aws/zinclabs/openobserve:latest

After the container starts, the README says to open http://localhost:5080 and log in with those credentials. The first real use is to send a log line and find it: point an OpenTelemetry exporter at that host and port, then query the stream with SQL in the Logs view. The README does not spell out the exporter configuration, so check the quickstart documentation link it provides before wiring a collector.

For a local trial without object storage, the repository ships a .env.example that sets ZO_LOCAL_MODE to true, along with ZO_ROOT_USER_EMAIL, ZO_ROOT_USER_PASSWORD, ZO_MAX_FILE_SIZE_ON_DISK, ZO_FILE_PUSH_INTERVAL, ZO_S3_BUCKET_NAME and RUST_LOG. Copy it to .env and edit the values rather than inventing new keys.

ZO_ROOT_USER_EMAIL = "[email protected]"
ZO_ROOT_USER_PASSWORD = "Complexpass#123"
ZO_MAX_FILE_SIZE_ON_DISK = 32
ZO_FILE_PUSH_INTERVAL = 10
ZO_S3_BUCKET_NAME = "zinc-dev"
ZO_LOCAL_MODE = true
RUST_LOG = "info"

The same file is the clearest signal of how the storage model is configured: ZO_MAX_FILE_SIZE_ON_DISK and ZO_FILE_PUSH_INTERVAL control how large a local file grows before it is pushed, and ZO_S3_BUCKET_NAME is where it goes. There is also a download.sh and downloadO2.sh in the repository root for non-Docker installs, and the README points to a High Availability deployment guide for clustered setups.

Where OpenObserve is the wrong tool

The strongest reason to avoid it is the licence, and it is worth reading before anything else. OpenObserve is AGPL-3.0. If you embed it in a product you distribute, or offer a modified version as a network service, the copyleft terms reach further than a permissive licence would. The repository contains a Cross.ent.toml and an enterprise Cargo feature, so the project clearly maintains a commercial track alongside the open source one; the README's Enterprise Edition section is where that boundary is described, and it is the section to read if your use case is close to the line.

The second limitation is operational rather than legal. The 140x storage claim is a comparison against Elasticsearch, not a guarantee about your bill. Parquet on object storage is cheap per byte, but you still pay for the bucket, for requests, and for whatever compute scans those files. The README does not publish a query-latency figure for large scans, so treat the performance claims as directionally useful and test against your own data volume.

The third is ecosystem breadth. OpenObserve is OpenTelemetry-native, which covers a great deal, but the README does not enumerate a catalogue of prebuilt vendor integrations the way a hosted commercial platform does. If your stack depends on a long tail of first-party integrations, count them before you migrate.

OpenObserve compared with Grafana and SigNoz

The closest comparisons are Grafana and SigNoz, and they differ in where the storage layer sits.

Grafana is primarily a visualization and query front end. It expects a backend per signal: Loki or Elasticsearch for logs, Prometheus or Mimir for metrics, Tempo or Jaeger for traces. You assemble the stack and you operate each piece. OpenObserve collapses that into one binary with one storage model, which removes a lot of integration work but also removes the freedom to swap a single component. If you already run a mature Prometheus and Loki setup, replacing it wholesale is a bigger project than adding a Grafana dashboard.

SigNoz is closer in ambition: it also targets logs, metrics and traces in one product and is also OpenTelemetry-centric. The difference the README emphasizes is the storage engine. OpenObserve writes Parquet to S3 and markets the resulting cost profile; SigNoz is built around ClickHouse. Both are self-hosted options with a commercial tier. The practical question is which storage engine your team can operate and back up. If you already run ClickHouse, SigNoz has less new surface area. If you already run S3 and want the database out of your operational scope, OpenObserve is the simpler story.

Maintenance, releases and what the repository tells you

The repository is not archived, and the most recent push recorded is 2026-08-28, the same timestamp as the v1.0.0-rc1 release. Two stable releases, v0.92.2 and v0.92.1, landed earlier that month. The root Cargo.toml still declares version 0.93.0, which is a reminder that the release candidate and the workspace version do not move in lockstep. Pin an explicit tag rather than tracking latest if you want reproducible upgrades.

Upgrade cost depends on how you deployed. A single Docker container with a mounted data directory is close to a restart plus a pull. A clustered deployment backed by object storage is a different exercise, and the README defers to the High Availability deployment guide rather than describing the procedure inline. There is no rollback procedure documented in the README, so plan your own before upgrading a production instance.

The licence question is the one that needs a human decision rather than a technical one. AGPL-3.0 governs the open source distribution; the enterprise feature flags and the Enterprise Edition section describe what sits outside it. This article cannot tell you whether your specific deployment triggers the copyleft obligations, and it should not try.

Editorial conclusion

Adopt OpenObserve if you want a single container or binary that ingests OpenTelemetry data and keeps Parquet files on S3, and if AGPL-3.0 fits how you ship software. Do not adopt it if you need a managed vendor with a long list of prebuilt integrations, or if you cannot accept the licence terms for a modified distribution. Before committing, verify three things: that the version tag you pin actually exists in the repository, that your object storage credentials work through ZO_S3_BUCKET_NAME and the related S3 variables rather than only in ZO_LOCAL_MODE, and that your retention window fits the storage budget you have.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes