SQLite Local AI Memory

What SQLite Local AI Memory does

SQLite Local AI Memory provides persistent memory for AI assistants through a local stdio MCP server. Memories, indexes, and notes are stored in a SQLite file on the user's computer rather than in a hosted vector database. The system separates immediate working context from longer-lived facts and maintains history when facts change.

Its memory model supports active tasks, decisions, and next steps, alongside durable information such as configuration details and preferences. Fact updates can preserve previous values and record why they were superseded. An incubator holds ongoing investigations so unresolved work can be retained for later consolidation.

How it works

Memory retrieval combines SQLite FTS5 BM25 keyword search with Int8 vector search. Keyword search is suited to exact identifiers, addresses, variable names, and error codes; vector search is intended to find related concepts expressed with different wording. Results are combined with reciprocal-rank scoring. Search also supports retrospective, point-in-time queries.

The consolidate operation runs the AutoDream maintenance cycle. It synthesizes daily progress, organizes active work, and can preserve unresolved investigations with an [UNRESOLVED_CASE] tag. Contradiction handling can archive an older fact and mark a newer value as active, while lineage retrieval exposes the fact's version history and supersede reasons.

The reasoning layer has three operating modes. Gemini can provide cloud-assisted organization and structured reasoning. Ollama can run the model and embedding components locally with qwen2.5-coder and nomic-embed-text. Without either option, the system falls back to local SQLite FTS5 storage and keyword search, but loses model-dependent filtering, contradiction arbitration, entity extraction, semantic search, and AutoDream consolidation.

Setup and configuration

The MCP configuration can launch the package with npx and pass environment variables through the client configuration:

{
  "mcpServers": {
    "sqlite-memory": {
      "command": "npx",
      "args": ["-y", "sqlite-local-ai-memory"],
      "env": {
        "GEMINI_API_KEY": "your-gemini-api-key"
      }
    }
  }
}

For an Ollama-backed setup, configure ORCHESTRATOR_MODEL with an Ollama model such as ollama/qwen2.5:1.5b and set OLLAMA_HOST to the Ollama service address. The server can also operate without API keys or Ollama, using its bare SQLite fallback.

Tools and capabilities

• save_fact stores an atomic fact and performs collision or contradiction auditing.
• search_memory runs hybrid FTS5 BM25 and Int8 vector retrieval, with point-in-time queries.
• get_fact_lineage reconstructs a fact's versions, changes, and supersede reasons.
• get_current_state reads the live working-memory dashboard and active incubator cases.
• consolidate performs background memory maintenance and daily progress synthesis.
• Local storage keeps the database, notes, and indexes in one SQLite file.

Limitations and notes

Model-dependent features require Gemini or Ollama. The no-model fallback remains usable for direct fact storage and local keyword search, but it does not provide the intelligent organization and semantic retrieval available with a model. Cloud-assisted mode sends reasoning work to Gemini, while Ollama supports an offline operating mode on local hardware.

The server is intended for local stdio use. Its documented MCP examples target Claude Desktop, Cursor, and VS Code. A client instruction set is recommended so an agent knows when to load current state, search before claiming it has forgotten information, save important decisions, and consolidate at session end.