Performance
Tuning guidance for recall latency, ingest throughput, and storage growth in Wolbarg.
What is it?
Practical notes on what dominates runtime cost and how to configure Wolbarg for speed vs quality.
Why does it exist?
Most latency is not “SQLite being slow” — it is embedding HTTP calls, rerank APIs, and scanning oversized candidate sets.
How it works — cost drivers
| Path | Dominated by |
|---|---|
remember | Embedding API + single insert |
recall | Query embed + vector scan (+ hybrid + rerank) |
ingest | Parse + N embeddings + batch insert |
compress | LLM tokens |
Tuning checklist
- Call
await ctx.ready()at startup to fail fast - Prefer metadata filters before raising
topK - Keep
thresholdslightly above 0 for noisy corpora - Use hybrid only when you need exact tokens
- Reserve rerankers for high-precision paths
- Pick chunk sizes intentionally (Chunking)
- Match embedding dimensions to your model and never silently change them mid-database
When should you use SQLite vs Postgres?
- SQLite — single node, lowest ops overhead
- PostgreSQL — multi-instance sharing and central ops
See Benchmarks for methodology and published numbers, and the live charts at /benchmarks.