3–10×
Lower cost than Elasticsearch
Hot data lives on S3, not on replicated always-on SSD. You pay for object storage plus the compute you actually query with.
Apache-2.0 · Rust · self-hosted
Open source search for AI agents.
3x cheaper than Elasticsearch. A storage-disaggregated search engine: S3 is the source of truth, local NVMe is a transparent cache, and compute nodes are disposable.
- BM25 + kNN
- one engine, one query path
- HNSW vector search
- Phase 1 complete
- Drop-in client
- OpenSearch-compatible Python
# pull and run the server
docker run --rm -p 8080:8080 \
ghcr.io/decover-tech/kosha:latest
# index, flush, search
export KOSHA_HOST=http://localhost:8080
export KOSHA_API_KEY=sk-kosha-dev
kosha index -n demo --file docs.jsonl
kosha flush -n demo
kosha search -n demo "breach"no JVM · no cluster to babysit · S3 + one binary
p50
3.6ms warm
87ms cold
p90
60ms warm
148ms cold
p99
150ms warm
280ms cold
Warm namespace
Cold namespace
Approach: 8 QPS for 1,800 s per phase, snapshot restored before each, single AWS m7i.8xlarge.
run 31653579479 @ dd365b7 · 2026-08-13
p50
124ms warm
123ms cold
p90
248ms warm
246ms cold
p99
481ms warm
612ms cold
Warm namespace
Cold namespace
Mean recall@10 is 0.947 over a 500-query sample. The cold phase returned 34 errors in 14,401 requests. These latencies are the cost of a recall fix that raised recall from 0.56, and the regression is still open — read them with that caveat.
run 31847559986 @ 765400c · 2026-08-14
Compare
An open alternative to Elasticsearch and Turbopuffer
Elasticsearch couples storage to stateful nodes. Turbopuffer separates them but only as a hosted service. Kosha does the separation in the open.
| Capability | Kosha | Elasticsearch | Turbopuffer |
|---|---|---|---|
| License | Apache-2.0, fully self-hosted | ELv2 / SSPL / AGPL, source-available | Closed source |
| Cost | 3–10× lower than Elasticsearch | Baseline | Usage-based vendor pricing |
| Storage | S3 is the source of truth; NVMe is a transparent cache | Replicated local disk on stateful nodes | Object storage, vendor-managed |
| Compute | Disposable stateless nodes, one Rust binary | Long-lived JVM cluster | Vendor-operated |
| Search | BM25 lexical + HNSW kNN in one engine | BM25 + kNN | Vector + full-text |
| Getting started | docker run, self-serve | Self-host or Elastic Cloud | Hosted signup only |
Benchmarks
Cheaper on cost, level on latency
At par
Query latency vs Turbopuffer
A read-through NVMe cache keeps working-set segments local, so warm queries never round-trip to object storage.
Phase 1
BM25 and HNSW shipped
Indexing, filtering, aggregation, wildcard, match-phrase, and ANN search work today. RRF fusion and rerank are next.
Measured latency for both suites is in the hero. Cost figures on this page come from list pricing, not from a measured workload.
Community
Built in the open, in Rust
Seven crates, an Apache-2.0 license, and a design doc you can argue with. Issues and pull requests are the roadmap.
- kosha-segment
- Segment format: inverted index, doc store, filter columns, HNSW graph
- kosha-cache
- Read-through NVMe SSD cache
- kosha-query
- BM25 scorer, ANN search, aggregations, filtering
- kosha-server
- HTTP API: index, search, stats, delete, flush