sqlite-vec and Qdrant are storage engines first; their durability is mostly “under the hood.” If your goal is a clean
local RAG system, owning that layer can be better when you want:
1. deterministic ingest semantics (append-only event log of chunks, then materialize state),
2. fast recovery from partial writes (replay only WAL since last checkpoint),
3. precise checkpoint boundaries tuned to your app (e.g., after every batch/conv/session ingest),
4. a single-file, dependency-light artifact you can own end-to-end.
That’s why it can be better than sqlite-vec/Qdrant in this specific case: not for raw ANN quality, but for operational
predictability + composability of ingestion, retrieval, and memory lifecycle in one library.
If you don’t care about that control and are fine with a managed server/extension model, built-ins are usually the
simpler and smarter choice. It already combines text + vector retrieval and reranking, so you can treat
remember(...) as ingestion and recall(query:) as search for any document
corpus.
It does not natively do “recency decay” (newer beats older) out of the box in
the core call signature. If you want recency weighting, add timestamps in
metadata and apply post-retrieval re-scoring or filtering in your app logic
(or query-time preprocessing).
- 0.84ms vector search at 10K docs (Metal, warm cache)
- 9.2ms first-query after cold-open for vector search
- ~125x faster than CPU (105ms) and ~178x faster than SQLite FTS5 (150ms) in
the same 10K benchmark
- 17ms cold-open → first query overall
- 10K ingest in 7.756s (~1289 docs/s) with hybrid batched ingest
- 0.103s hybrid search on 10K docs
- Recall path: 0.101–0.103s (smoke/standard workloads)