The migration story is the reason to pick this over a file-only memory server: the schema and the vector search are the same whether the database is on your laptop or hosted, so a personal memory store can become a shared one without a rewrite. If you run it under WSL, use Linux-style paths for the database file — the README calls that out specifically.
A memory server implementing the standard MCP memory interface on top of libSQL. Entities carry embeddings, so retrieval can be similarity-based rather than exact-match, and the same server runs against a file on disk or a remote libSQL database.
- Entities created and updated with embeddings, deleted when they are no longer wanted, and searched by similarity
- Relations created between entities, deleted, and queried to find what an entity connects to
- Vector search runs on libSQL's own vector operations rather than a separate index service
- One environment variable switches between a local SQLite file and a remote libSQL database — the same server, the same data model
- Remote databases authenticate with a token rather than an open connection
The npm package mcp-memory-libsql, version 0.0.14, run over npx. LIBSQL_URL selects the store: a file: URL for local SQLite, or a libsql:// URL for a remote database such as Turso, in which case LIBSQL_AUTH_TOKEN is also required. With nothing set it falls back to file:/memory-tool.db in the current directory.
One command — npx -y mcp-memory-libsql