Low-resource vector memory: sqlite-vec before bloat
Embedded vector search with zero daemon, a 3 MB wheel, and full SQL filtering. Obsidian vault ingestion, markdown frontmatter parsing, and incremental indexing — all running on a laptop. This is what replaced ChromaDB on the AIres memory layer.
Why not a real vector DB
Because for a single operator’s research corpus, “a real vector DB” means a separate daemon, a service to keep up, a port to expose, and a backup story to write. sqlite-vec is a SQLite extension. The whole index lives in one file. No service. No port. cp to back up.
What ships in the memory pack
- Obsidian vault scanner with frontmatter awareness.
- Incremental indexer — only re-embed files that actually changed.
- Hybrid SQL + vector queries (filter by tag, then rank by similarity).
- Notion export ingester for users migrating away from cloud notes.
Trade-offs we accept
One process, one file, one disk. If the corpus grows past a million chunks, sqlite-vec starts to wobble. That ceiling is far above a single operator’s working set, and the migration path to a real vector store is “export, re-embed, point new client at new endpoint” — not a rewrite.
Start small. Keep it on disk. Move up only when the corpus, not the framework, demands it.