Quickwit

Last reviewed Aug 26, 2026 · 816 words

Quickwit's pitch reduces to one number: the index lives on object storage, so a year of logs costs S3 (or MinIO) prices, typically a quarter or less of what the same bytes cost on the block storage an Elasticsearch node insists on. Searchers pull only the index slices a query touches, which means a 1 GB RAM node can serve queries over terabytes it never fully holds. The trade is that Quickwit is built for append-only data (logs, traces, events) and has no interest in updating a document once written. If that describes your workload, it is the most economical self-hosted log search I know of; if you need to edit records, look elsewhere.

Decoupled storage changes the hardware conversation

A conventional log cluster couples compute and storage: every node needs fast local disk for the shards it owns, and scaling search means scaling expensive disk. Quickwit splits the roles. Indexers turn incoming documents into immutable "splits" (self-contained index files built on the Tantivy library) and upload them to a bucket; searchers open those splits on demand with range requests and a local cache. The metastore, which tracks which splits exist, is a single file for one node or PostgreSQL for a cluster.

For a self-hoster the consequence is pleasant: one container with 1 GB of RAM, a bucket on MinIO or a cloud provider, and storage that grows at object-storage prices. Cold data is the normal case, not a tier you have to design.

The single-node quickstart works as documented

mkdir qwdata
docker run --rm -v $(pwd)/qwdata:/quickwit/qwdata \
  -p 7280:7280 quickwit/quickwit run

That starts REST on 7280 and gRPC on 7281 with a file-backed metastore and local split storage. To point it at a bucket, give it a config/quickwit.yaml with default_index_root_uri: s3://logs-bucket/indexes and the usual S3 credentials as environment variables, including QW_S3_ENDPOINT for MinIO. Then create an index from a YAML index config: Quickwit is schema-first, and a doc_mapping with a timestamp field is required for time-range pruning to work. Skipping that field is the one mistake that makes it feel slow.

Elasticsearch-compatible in, Grafana out

Ingest is where compatibility earns its keep. The _bulk and _search endpoints speak enough of the Elasticsearch API that Vector, Fluent Bit or an OpenTelemetry Collector configured for Elasticsearch output will ship logs with a URL change. For traces, Quickwit accepts OTLP over gRPC and HTTP natively, and it exposes a Jaeger-compatible gRPC API, so Grafana's Jaeger datasource can browse Quickwit traces without a translation layer. There is also a first-party Grafana datasource plugin for log queries.

Query syntax is Lucene-like: level:error AND service:api, phrase queries in quotes, ranges on numeric fields. Aggregations cover terms, histograms and stats, which is enough for a Grafana panel of error rates per service, though anyone expecting Kibana-style dashboards inside Quickwit itself will find only a bare search UI.

Where Loki is the better pick

Loki also stores on object storage and also pairs with Grafana, so the two get compared constantly. The split is full-text indexing. Loki indexes only labels and greps the content at query time; it is cheaper to ingest and lighter to run, and for a homelab with 5 GB of logs a month it is the simpler choice. Quickwit indexes the text, so a needle-in-haystack query over 6 months returns in seconds rather than after a scan of every chunk in the range. Once volume passes tens of gigabytes a day, or you need traces and logs in one engine, Quickwit starts winning; below that, Loki's operational simplicity is hard to argue with. Neither is a general-purpose search engine; for product or document search read the search category guide instead.

The ownership question

Datadog acquired the company behind Quickwit at the start of 2025 and said the open-source project would continue under Apache-2.0. Releases have kept coming, but anyone building a multi-year retention plan on it should note that the corporate steward now also sells a competing hosted product. Splits are plain files in a bucket and the format is documented, so the exit is a re-index rather than a hostage situation.

What I'd do

Below 10 GB of logs a day: Loki with Grafana and stop reading. Above that, or the moment you want traces and logs searched from the same place, Quickwit on a single 2 GB node, splits on MinIO or S3, Vector shipping via the Elasticsearch sink, a timestamp field in every index. Set a retention policy in the index config from day one, keep the metastore file in your backups, and treat it as an append-only archive, which is exactly what it is good at.