Quickwit

What it is

Quickwit is a search and analytics engine built specifically to run against object storage (S3, GCS, Azure Blob) instead of local disk. It's the open-source answer to "I want Elasticsearch-style full-text search and log analytics without paying for a fleet of stateful nodes holding hot data." Written in Rust, it decouples compute from storage, so you can scale search nodes independently and let data sit cheaply in a bucket between queries. Core use cases: log search, distributed tracing, and general append-heavy analytics where sub-second query latency on cold storage matters.

Who builds it and why

Quickwit was built by a small team of infra/search engineers (French founders, ex-Algolia and search-infra backgrounds) who bet that object storage would become the default backing store for observability data, and that existing engines (Elasticsearch, Loki) hadn't been designed cloud-storage-first from day one. The company Quickwit Inc. was acquired by Datadog in 2023, which folded the team into Datadog's log/observability backend work. The open-source project has continued to receive commits since then, but the commercial roadmap now runs through Datadog's priorities rather than a standalone Quickwit Cloud product. Worth knowing before you plan around it long-term.

Production readiness signal

• 11,377 GitHub stars, 117 contributors — solid community traction for a niche infra project, though contributor count is fairly concentrated (typical for engine-level Rust projects).
• Last commit dated 2026-07-01 — actively maintained, not abandoned.
• Apache-2.0 license — no rug-pull risk on licensing terms.
• CNCF maturity: not publicly available (it is not a CNCF project, it's an independent open-source project under company/Datadog stewardship).
• No public data on founding date or SLA-backed enterprise support tiers post-acquisition.

Net: the code is real, active, and used in production by companies running log/tracing pipelines at scale. But post-acquisition, the commercial support story is murkier than a standalone vendor. Check current release notes and issue velocity before betting critical infra on it.

Who should use this

• Teams with large volumes of log/trace data where storage cost is the dominant pain point and you want to keep data in S3-class storage rather than provisioning hot SSD-backed clusters.
• Rust-comfortable infra teams willing to operate and debug the engine themselves — this is not a fully managed SaaS-first product anymore.
• Organizations already running OpenTelemetry pipelines looking for a native, cost-efficient search backend rather than shipping everything into a hosted vendor.

Who should NOT use this

• Teams needing turnkey managed hosting with vendor support SLAs — the standalone commercial offering is no longer the clear path it was pre-acquisition; you're closer to self-hosting OSS than buying a product.
• Small-scale shops with modest log volume — Elasticsearch or even Loki will be simpler to operate and you won't see the storage-cost benefit that justifies Quickwit's added complexity.
• Teams that need a mature ecosystem of plugins, dashboards, and third-party integrations — Quickwit's ecosystem is thin compared to Elastic's.
• Anyone requiring rich aggregation/analytics parity with Elasticsearch's full feature set (certain query types and dashboarding integrations are still catching up).

Alternatives

• Elasticsearch/OpenSearch — much larger ecosystem and query feature set, but higher storage and ops cost at scale.
• Grafana Loki — cheaper and simpler for log-only use cases, but weaker full-text search performance and query flexibility.
• ClickHouse — better fit if your primary need is structured analytics/aggregation rather than full-text log search.

Pricing

Fully open source under Apache-2.0 — no license fees, self-host and operate yourself. Prior to the Datadog acquisition there was a "Quickwit Cloud" managed offering; its current availability and pricing post-acquisition is not publicly available, so assume self-hosting is your primary path today.