Benchmarks
Ketebe will not market latency, throughput, scale or cost numbers without a workload definition that other people can reproduce.
Why this page exists
Retrieval systems are unusually easy to benchmark badly. Index shape, vector dimensions, metadata selectivity, fusion strategy, reranking, ingestion pressure, hardware, durability settings and cache warmth can all change the result. Ketebe treats benchmark methodology as part of the product contract.
Benchmark profiles
Dense, sparse and hybrid query profiles with explicit dataset shape, top-k, filters, fusion and reranking behavior.
Record and document ingestion under defined durability, embedding and indexing conditions.
Restart, crash recovery and rebuild time with known WAL and segment state.
Search while writes, async jobs or continuous ingestion are active instead of testing isolated happy paths only.
What a credible result must include
- Ketebe version and commit.
- CPU, memory, storage and deployment topology.
- Dataset size, vector dimensions and metadata shape.
- Query mix, top-k and search profile configuration.
- Warm-up method and run duration.
- Latency percentiles, throughput and error rate together.
- Any background ingestion, embedding, compaction or recovery activity.