// the find
quickwit-oss/quickwit
Cloud-native search engine for observability. An open-source alternative to Datadog, Elasticsearch, Loki, and Tempo.
Quickwit is a distributed search engine built specifically for storing and querying observability data (logs and traces) on object storage like S3. It decouples compute from storage — indexers and searchers are stateless, data lives in S3 — which is the core architectural bet that makes it cheaper than Elasticsearch at scale. It's Elasticsearch API-compatible and OTEL/Jaeger-native, targeting teams drowning in Elastic bills.
1. The storage-compute separation is architecturally sound and not just marketing: stateless indexers write immutable splits to S3, searchers fetch and cache them on demand. You can scale search and indexing independently, and your storage cost drops to S3 pricing instead of SSD-backed nodes.
2. The project publishes honest Architecture Decision Records including a 'gaps' directory that documents what they deliberately haven't built yet (no per-point deduplication, no multi-level caching, no leading-edge prioritization). That kind of transparency is rare and useful for evaluating production readiness.
3. OTEL and Jaeger support is native, not an afterthought — you can point your existing collectors directly at Quickwit without a translation layer.
4. They built their own actor system (quickwit-actors) and use TLA+ specs for distributed protocol verification. That's the kind of engineering discipline you want in software that's managing your production logs.
1. Still at 0.8 — not 1.0. Breaking config and API changes are still on the table, and the project itself lists significant gaps: no metrics support yet (it's on the roadmap), which means you still need Prometheus/VictoriaMetrics for a complete observability stack.
2. High availability indexing is only available when using a Kafka source. If you're ingesting via the HTTP API or file sources, you don't get HA on the write path — this is documented but easy to miss before you're in production.
3. The Elasticsearch API compatibility is a subset, not the full thing. The docs are clear about what's missing, but if you're running complex aggregations or using less common ES query DSL features, you'll hit gaps and need to test carefully before migrating.
4. Operationally, the distributed mode has several components to run (control plane, metastore, indexers, searchers, janitor) — more moving parts than a single Loki or simple Elasticsearch cluster, and the community/tooling ecosystem is a fraction of the size.