Monomind 2.3.1: Removing LanceDB, Going Local-First for Memory
600MB of native vector-DB dependencies out, local SQLite and in-process embeddings in
2.3.1 replaces a cloud-shaped vector database dependency with a single local SQLite file.
Monomind's memory system used to depend on LanceDB - an embedded vector database shipped via @lancedb/lancedb and apache-arrow. It worked, but it carried roughly 600MB of native dependencies, which made installs heavier and cross-platform builds more fragile than they needed to be.
In the 2.3.1 release (July 18, 2026), we removed LanceDB entirely. Memory storage now runs on local SQLite, with local embeddings computed in-process. Nothing about how memory is used changed - what changed is what's running underneath it.
LanceDB Removed - Local SQLite + Local Embeddings
better-sqlite3 as the primary driver, with a sql.js WASM fallback when the native binary can't load.
Local MiniLM/HuggingFace models run in-process via transformers.js - no API key, no cloud call.
A pure-JS HNSW index exists only as a dormant fallback for native SQLite load failures - not the active path.
Why LanceDB had to go
Native dependency weight without a matching payoff for a local-first tool
LanceDB gave monomind a working vector store early on, but it came bundled with apache-arrow and native binaries that added significant install weight - around 600MB - for a tool meant to run comfortably on a developer's own machine.
For a project whose whole premise is local-first operation, a heavy native dependency chain is friction: slower installs, more platform-specific failure modes, and a bigger attack surface to keep updated. 2.3.1 removes that dependency chain outright rather than trying to slim it down.
Key Takeaways
- ✓LanceDB (@lancedb/lancedb + apache-arrow) is fully removed as of 2.3.1
- ✓That dependency chain accounted for roughly 600MB of native install weight
SQLite storage, local embeddings
Text and vectors live in one local database file
In place of LanceDB, monomind now stores memory text and embedding vectors in local SQLite, using better-sqlite3 as the primary driver. Where native SQLite binaries can't load - certain platform or environment combinations - monomind falls back to sql.js, a WASM build of SQLite, to keep memory working without a native compile step.
Embeddings themselves are computed locally too: monomind runs MiniLM/HuggingFace models in-process via transformers.js. There's no call out to a hosted embeddings API and no API key required to generate them - the model runs on your own hardware, on your own data.
There's also a pure-JS HNSW vector index in the codebase, but it's worth being precise about what it is: a dormant fallback path, used only if native SQLite binary loading fails on a given system. It is not the active index and not a co-equal part of the standard retrieval path - SQLite is.
# store and retrieve memory using local SQLite + local embeddings - no external services
npx monomind@latest memory store --key "pattern-auth" --value "JWT with refresh tokens" --namespace patterns
npx monomind@latest memory search --query "authentication patterns" --namespace patterns
npx monomind@latest memory statsKey Takeaways
- ✓Primary backend: local SQLite (better-sqlite3), with sql.js WASM as a cross-platform fallback
- ✓Embeddings run locally via MiniLM/HuggingFace models through transformers.js - no API key needed
- ✓The pure-JS HNSW index exists only as a dormant fallback for native SQLite load failures, not the active index
How retrieval works now
Dense embeddings plus lexical search, and a standalone package
Retrieval in monomind combines dense embedding similarity with lexical BM25 search, fusing the two so memory search can match on both semantic meaning and exact keywords. This logic sits on top of the SQLite-backed storage described above.
The underlying memory engine is also published independently as @monoes/memory on npm (currently at v1.0.14), for anyone who wants the storage and embedding layer outside of the full monomind CLI.
Monomind itself is Apache-2.0 licensed. That hasn't changed with this release - only the memory backend has.
“Removing LanceDB wasn't about chasing a benchmark - it was about matching the dependency footprint to what a local-first tool should actually require.”
- Monomind Core Team
Key Takeaways
- ✓Retrieval fuses dense embedding search with lexical BM25 matching
- ✓The memory engine is also available standalone as @monoes/memory (npm, v1.0.14)
- ✓Monomind is Apache-2.0 licensed
Conclusion & Future Outlook
2.3.1 is a backend migration, not a new feature - LanceDB is out, local SQLite and in-process embeddings are in. The result is a lighter, more portable memory system with no cloud vector database and no API key in the loop.
This release is also the foundation for what comes next: later 2.3.x and 2.4/2.5 releases build the Second Brain document-knowledge features on top of this same local storage layer - that's a story for the next post.
Deploy Monomind Digital Workers Today
Run open-source AI agent teams on your own infrastructure or hire Monoes Workforce to build and audit fully managed operations.