Quickwit

Quickwit is an open-source search engine built for observability data such as logs and distributed traces, with metrics support on its roadmap. It's designed from the ground up to search directly on cloud object storage such as S3, Azure Blob Storage, and Google Cloud Storage, decoupling compute from storage so indexers and searchers stay stateless. Quickwit exposes an Elasticsearch/OpenSearch-compatible API, so existing log shippers and Elasticsearch clients can often point at it with minimal changes.

Key features

• Sub-second search on cloud storage: optimized IO paths and index structures make search fast directly against S3-compatible storage.
• Elasticsearch-compatible API: works with existing Elasticsearch or OpenSearch clients, including popular query DSL and aggregations.
• Native OTEL and Jaeger support: ingest OpenTelemetry logs and traces, or plug directly into Jaeger for distributed tracing.
• Schemaless or strict indexing: index data without a predefined schema, or enforce one when needed.
• Stateless, decoupled architecture: indexers and searchers scale independently and can be added or removed in seconds.
• Multiple ingest sources: native support for Kafka, Kinesis, and Pulsar as indexing sources.
• Multi-tenancy and retention policies: partition indexes and configure automatic data expiration, including delete tasks for GDPR use cases.

Ideal use cases

Quickwit targets teams operating existing log and tracing pipelines who are hitting the storage or compute cost of a self-managed Elasticsearch or Splunk cluster, particularly at high log volumes where keeping months of data on attached SSDs becomes expensive. Because it searches directly against object storage, teams can retain far more historical log and trace data at object-storage prices instead of paying for large, always-on compute and local disk to hold an index. The Elasticsearch-compatible API lowers the switching cost for teams with existing Kibana-style dashboards, Vector or Fluent Bit log shippers, or applications built against the Elasticsearch client library, since much of that tooling can point at Quickwit with configuration changes rather than a rewrite. Native Jaeger and OTEL support fits teams standardizing on OpenTelemetry for both logs and traces and wanting a single backend for both signal types rather than separate systems. Multi-tenancy and retention policies suit platform teams offering log search as a shared service to multiple internal teams or customers, where per-tenant data isolation and automatic expiration are operational requirements.

Self-hosting and deployment

Quickwit ships as a self-hosted binary and is Kubernetes-ready through an official Helm chart. Because search is stateless and compute is decoupled from storage, indexer and searcher nodes can scale out independently in response to load. Teams migrating from Elasticsearch or OpenSearch can typically redirect existing log shippers, such as Vector, Fluent Bit, or Syslog, at Quickwit's ES-compatible ingest API, and an extra_headers config option lets Quickwit impersonate a specific Elasticsearch or OpenSearch version for clients that check it. High availability is supported for search; HA indexing requires a Kafka source.