Quickwit keeps index splits in object storage
Quickwit breaks each search index into independent splits, writes those files to S3, Azure Blob Storage, Google Cloud Storage, an S3-compatible service, or local disk, and keeps split metadata in a metastore. Search workers fetch the pieces needed for a query instead of owning permanent shards on attached disks. Compute can then change without moving the complete index between machines. That design is most useful for observability data whose retained volume grows faster than the search fleet.
Logs and distributed traces are the finished use cases in version 0.9. OpenTelemetry, Jaeger, Kafka, Pulsar, Kinesis, SQS, file ingestion, and HTTP APIs cover several common paths into the system. Metrics are a different story: the README still calls them roadmap work, while the 0.9 release says its Parquet and DataFusion metrics code is an early prototype excluded from published binaries and images. Buyers seeking one store for all 3 telemetry types should wait or pair Quickwit with a metrics database.
Four services plus a janitor make up a cluster
The architecture guide separates Quickwit into 4 main services and 1 maintenance service. Searchers execute queries, indexers build splits, the metastore tracks them, and the control plane assigns indexing work. A janitor handles garbage collection, delete tasks, and retention policies. A single machine can use local files, but a cluster normally adds PostgreSQL for metadata and object storage for index data. This is infrastructure software, even though a prebuilt binary makes the first local start look simple.
High availability has a sharp limit. Search nodes are stateless and distribute work, while the README says highly available indexing is available only with Kafka. A production design therefore needs object-store credentials, PostgreSQL backup and recovery, service discovery, source offsets, retention settings, and capacity for search caches. Teams using another ingestion source should test what an indexer restart does to delivery. Quickwit's control plane reduces manual shard placement; it does not remove the surrounding services.
What happened when we ran it
Our sandbox installed commit a39730c in 67 seconds and pulled 824 Rust packages. The build succeeded, but it took 560 seconds on 3 CPUs with 12 GB of RAM. The clean checkout itself held 1,557 files, about 368,733 lines of source, and used 23.6 MB before compilation. That is a large contributor experience compared with downloading a release binary, and it should influence CI cache and feedback-time expectations.
Cargo test ran for 702 seconds and ended with exit code 101. It reported 2,176 passed and 2 failed out of 2,178. The supplied log tail does not name both failing tests or give their causes. It does show a quickwit-indexing library result with 230 passed, 1 failed, and 1 ignored, followed by Cargo's command to rerun that package. We will not guess why the 2 tests failed. The repository had 13 CI workflow files and no top-level tests directory or Dockerfile.
Elasticsearch compatibility ignores some bulk actions
Quickwit labels its Elasticsearch and OpenSearch API incomplete. The compatibility page says _bulk accepts only the create action; delete and update actions are ignored. Quickwit has no document ID behavior matching Elasticsearch, and indexing errors are written to server logs instead of returned in the bulk response. The endpoint also limits a payload to 10 MB. A shipper that only creates immutable log events may work, while a search application that updates records needs a different path.
Search compatibility is broader than bulk ingestion, with _search, multi-search, scroll, selected cat endpoints, query DSL features, and aggregations. It is still a checklist, not a promise of drop-in parity. OpenSearch is the safer move when existing clients depend on a wider Elasticsearch surface. Loki fits teams centered on logs and LogQL. Native Elasticsearch remains the direct choice when its API and integrations are requirements. Run captured production requests against Quickwit before changing a sender or dashboard.
Version 0.9 blocks a mixed-version rolling upgrade
Quickwit 0.9 makes Ingest V2 the default on the existing ingest route and removes the dedicated V2 route. The upgrade guide requires a metastore backup, then says every 0.8 node must stop before any 0.9 node starts because mixed clusters are unsupported. First write on 0.9 runs metastore migrations. Returning to 0.8 requires restoring the backup. Metric names and some configuration fields also changed, which can affect dashboards and alerts even when stored index data needs no reindexing.
Current issue activity gives operators more to test. Issue 6531 describes persistent no open shard found on ingester errors after some indexer restarts in a production 0.9 environment; it had 13 comments and was updated September 6. Issue 6719 reports an estimated 1.4 GB of unaccounted heap in one production setup and proposes that cache entry sizing omits request data. The reporter had not proved the root cause, so treat it as an investigation, not a confirmed memory defect.
September pushes continue after the July 0.9 release
GitHub recorded 11,582 stars and a last push on September 8, 2026, the date of commit a39730c. Search results returned 666 open issues and 141 open pull requests. Those counts show a large project with active work and a large queue; they do not equal 666 confirmed bugs. The latest release, v0.9.0, was published July 25 with Ingest V2, Jaeger v2 support, optional REST mTLS validation, a health-check server, and an SQS source.
The code activity after that release matters more than the README banner, which still announces version 0.8. Quickwit has credible architecture and serious operational documentation, but the 560-second build and failed 2,178-test run argue for pinning a revision and testing it with your own ingest restarts, query set, and upgrade rehearsal. Its best buyer has enough retained logs or traces to value object storage and enough platform capacity to operate 5 service roles without pretending the search engine is a single binary in production.