Sqlite Memory Mcp

SQLite Memory MCP Server

Governed cross-agent memory for coding agents

Claude and Codex can share one provenance-rich knowledge graph with approval-aware promotion workflows.

• Hybrid retrieval — BM25/FTS5 keyword search fused with optional semantic (sqlite-vec) results via Reciprocal Rank Fusion, so recall does not depend on exact keywords.
• Provenance + reviewable promotion — memory mutations carry provenance, and candidate claims move to canonical facts through an approval-aware promotion gate (human_confirmed, plus policy-gated multi-evidence) instead of silent rewrites.
• Cross-agent MCP memory with bridge sync — one local SQLite knowledge graph any MCP client can read and write, with bridge tools that sync shared entities across machines.

[](https://github.com/RMANOV/sqlite-memory-mcp/actions/workflows/ci.yml)

It is a production-quality, local-first MCP memory stack: a single SQLite file under WAL concurrency (10+ sessions), FTS5 BM25 search, session tracking, task management, bridge sync, collaboration workflows, and a native system-tray task manager. The core 9 knowledge-graph tools are drop-in compatible with @modelcontextprotocol/server-memory; companion FastMCP micro-servers add more tools for sessions, tasks, bridge sync, collaboration, entity linking, and intelligence/multi-agent workflows. A PyQt6 desktop app and standalone automation scripts ship alongside. See the [Tool Reference](#tool-reference) for the exact per-server tool counts.

Technical deep-dives

• Medium: The Amnesiac That Learned to Remember
• Dev.to: The Amnesiac That Learned to Remember — Building a Brain for Claude Code
• Dev.to: How a SQLite WAL Fix Grew into a 54-Tool MCP Memory Stack

Why SQLite?

Existing MCP memory servers use JSONL files, cloud APIs, or heavyweight databases. Each has trade-offs that hurt real-world Claude Code usage:

• JSONL files (official MCP memory) -- file locks break with 2+ concurrent sessions. Data corruption is a matter of time.
• Cloud APIs (Mem0, Supabase) -- latency, API keys, privacy concerns, vendor lock-in.
• Heavy databases (Neo4j, ChromaDB, Qdrant) -- Docker, config files, resource overhead for what is essentially a key-value store with search.

SQLite hits the sweet spot:

• Single file -- memory.db is the entire database. Back it up with cp.
• Zero config -- No server process, no Docker, no API keys.
• ACID transactions -- Writes never corrupt, even on power loss.
• WAL mode -- Multiple concurrent readers and writers. 10+ Claude Code sessions, no conflicts.
• FTS5 -- Full-text search with BM25 ranking built into the standard library.
• stdlib -- sqlite3 ships with Python. No additional binary dependencies.

Features

• WAL mode -- 10+ concurrent Claude Code sessions with no file locking conflicts
• Hybrid search (BM25 + semantic) -- FTS5 keyword search fused with optional sqlite-vec cosine similarity via Reciprocal Rank Fusion, then re-ranked with 6 contextual signals (recency, project affinity, graph proximity, observation richness, canonical facts, active session)
• Session tracking -- Save and recall session snapshots for context continuity across restarts
• Task management -- Structured task CRUD with typed queries, priorities, sections, due dates, and recurring tasks
• Kanban board -- Optional HTML report generator for visual task overview via GitHub Pages
• Cross-project sharing -- Optional project field scopes entities; omit it to share across all projects
• Cross-machine sync -- Bridge tools push/pull shared entities between machines via a private git repo
• Provenance + approval-aware promotion -- Mutations carry provenance; candidate claims promote to canonical facts through a review gate (human_confirmed / policy-gated multi-evidence). See [Advanced & operator topics](#advanced--operator-topics)
• Drop-in compatible core -- All 9 tools from @modelcontextprotocol/server-memory work identically in sqlite_memory, with many more tools available from companion servers (see [Tool Reference](#tool-reference) for exact per-server counts)
• Zero required dependencies beyond stdlib -- Only fastmcp is required for MCP protocol; sqlite3 is Python stdlib. Optional orjson, sqlite-vec, and sentence-transformers add speed and semantic search
• Automatic FTS sync -- Full-text index stays in sync with every write operation
• JSONL migration -- Optionally import existing memory.json knowledge graphs on first run

FAQ: how is this different from sqlite.ai / sqlite-vector?

sqlite.ai is adjacent, not identical. It is a broader SQLite platform around cloud sync, extensions, AI inference, vector search, agent memory, and MCP tooling. Its related projects include sqlite-memory, a Markdown-based agent memory system, and sqlite-vector, a vector-search extension for embedded SQLite workloads.

sqlite-memory-mcp is focused on local-first MCP memory governance for coding agents, not on vector search as the center of the product:

• WAL-backed task, session, entity, and note memory in one local SQLite file
• FTS5-first retrieval, with vector search as an optional backend
• cross-machine bridge sync for private multi-machine workflows
• event/provenance tracking for memory mutations
• reviewable consolidation instead of silent memory rewriting
• debate/protocol workflows for conductor, executor, and devil's advocate agents
• an explicit OSS/premium runtime boundary with signed entitlement, manifest,

and policy checks

sqlite-vec is therefore not the product center; it is one possible local retrieval backend. If sqlite-vector proves better for this workload, it can become a candidate backend. The harder problem this project targets is memory governance: how agents remember, revise, sync, debate, and promote durable context without turning the memory store into an unreviewable pile of contradictions.

Advanced & operator topics

The features above are the core. The capabilities below are deliberately kept out of the hero because they matter to operators, not first-time users. Each links to its canonical document.

Core path vs advanced path

For a single canonical operator map of what is on the everyday core path versus the advanced / optional path — plus the frozen allowed / forbidden external-claim set and the D2 (code-change) triggers — see [docs/ops/CORE_VS_ADVANCED_PATH.md](docs/ops/COREVSADVANCED_PATH.md).

• Core path (load-bearing, start here): sqlite_memory, sqlite_tasks,

sqlite_session; provenance / knowledge-links; bridge resilience; reflect / audit discipline; addressed debate routing; entity hygiene.

• Advanced / optional path (opt in as needed): sqlite_collab / P2P

(advanced / optional shared-knowledge surface); premium / airlock (an operator / private-runtime boundary, excluded from external-facing feature claims); the vector semantic backend (an optional backend with FTS5 fallback); and the advanced sqlite_intel / debate operations.

These labels describe posture and emphasis. Nothing here is removed, deprecated, disabled, or scheduled for removal; every server and tool below stays present and supported. The 7-microserver split is current MCP-visibility / ergonomics design, not a consolidation target — the [Tool Reference](#tool-reference) and its server / tool counts are unchanged.

Intelligence v2 — claims, governance, and provenance

The sqlite_intel server turns raw memory into reviewable knowledge. It extracts candidate claims, queues clarifications, records human answers, and promotes claims to canonical facts through an approval-aware gate (promote_candidate: human_confirmed always allowed; multi_evidence is policy-gated; sensitive scopes require explicit human confirmation). Every mutation can carry a provenance link, and audit_memory / replay_memory make the history inspectable. Consolidation runs through reflect_audit (Phase 0.5) — deterministic SQL with no LLM cost per run. See [docs/REFLECT_AUDIT_DEMO.md](docs/REFLECTAUDITDEMO.md).

Debate / multi-agent protocol

For workflows that coordinate multiple agents (conductor, executor, devil's advocate) across sessions, the sqlite_intel debate tools provide a single per-topic channel with role-aware watermarks, claim/reclaim, and escalation. This is an advanced coordination layer, not required for memory use. See [docs/DEBATE_PROTOCOL.md](docs/DEBATEPROTOCOL.md) and [docs/ops/DEBATE_OPERATIONS.md](docs/ops/DEBATEOPERATIONS.md).

Optional private-runtime boundary

This OSS repo includes a public contract for separately configured private extensions. It defines entitlement, artifact-manifest, control-policy, audit, revoke, and bootstrap surfaces, but does not include private business logic, private entitlements, signing keys, proprietary connectors, or private ranking/governance rules. Private extensions are not loaded by default; they require an explicit configured entrypoint, local owner approval, and the relevant signed entitlement / manifest / policy checks.

Operator wiring and the public contract are documented in:

• [docs/ops/PREMIUM_BOUNDARY.md](docs/ops/PREMIUM_BOUNDARY.md) — operator wiring and verification
• [docs/ops/RELEASE_CONFIDENCE.md](docs/ops/RELEASE_CONFIDENCE.md) — v3.7.2 release-quality checklist
• [premium_contract.py](premium_contract.py) — public contract for the private repo
• [docs/premium/entitlement.schema.json](docs/premium/entitlement.schema.json) — entitlement schema
• [docs/premium/private_extension_contract.md](docs/premium/privateextensioncontract.md) — private extension contract
• [templates/private_premium_repo/](templates/privatepremiumrepo/) — public-safe bootstrap template

Pricing is intentionally not published here; serious prospects receive a scoped questionnaire, then a customized offer.

External claim boundary (frozen claim-set)

For external / diligence material, the project commits to a frozen claim-set, stated canonically in [docs/ops/CORE_VS_ADVANCED_PATH.md](docs/ops/COREVSADVANCED_PATH.md).

Allowed: local-first governed cross-agent memory; provenance / knowledge-links and approval-aware promotion; the deterministic reflect_audit audit gate; addressed debate routing bounded to addressed messages, cursors, no_action, role watermarks, and audit logs; hybrid retrieval with an FTS5 baseline and an optional vector backend (FTS5 fallback); entity hygiene / merge with an audit trail; and bridge cross-machine resilience as conflict / recovery discipline against no-resurrect / no-data-loss failures. Posture: application- enforced append-only governance, local-first, civilian-dogfooded, single-operator, test-backed.

Forbidden: defence validation / accreditation / certification; "immutable" / WORM / tamper-evident or hash-chain claims (until shipped); shipped STRIX ↔ sqlite_memory integration; edge / on-hardware deployment; premium / airlock as a named external feature; an absolute no-data-loss guarantee; vector search as the product center or a required baseline; and unbounded "production" claims (only production-quality, single-operator, no external customers or deployment).

Competitor Comparison

| Feature | sqlite-memory-mcp | Official MCP Memory | claude-mem0 | @pepk/sqlite | simple-memory | mcp-memory-service | memsearch | memory-mcp | MemoryGraph | |---|---|---|---|---|---|---|---|---|---| | Storage | SQLite | JSONL file | Mem0 Cloud | SQLite | JSON file | ChromaDB | Qdrant | SQLite | Neo4j | | Concurrent 10+ sessions | WAL mode | file locks | cloud | no WAL | file locks | yes | yes | no | yes | | Hybrid search (BM25 + vector) | yes (RRF fusion) | substring | no | no | no | vector only | vector only | no | Cypher only | | Session tracking | built-in | no | no | no | no | no | no | no | no | | Task management | built-in | no | no | no | no | no | no | no | no | | Cross-project sharing | project field | no | no | no | no | no | no | no | no | | Drop-in compatible | 9/9 tools | baseline | no | partial | no | no | no | partial | no | | Setup effort | pip install | npx | API key + pip | pip | npx | Docker + pip | Docker + pip | pip | Docker + Neo4j | | Dependencies | sqlite3 (stdlib) | Node.js | Cloud API | sqlite3 | Node.js | ChromaDB | Qdrant | sqlite3 | Neo4j |

Where this sits in the ecosystem

• Beads. sqlite-memory-mcp can sit beside Beads. Beads is an issue/work-tracking layer for agents; sqlite-memory-mcp is a governed memory layer. There is no shipped Beads adapter — the ready_context tool offers a ready/prime work surface that is the cross-project/cross-machine analog of bd ready / bd prime, so the two can coexist in the same workflow.
• Codex Memories. OpenAI's Codex has its own memory feature, and the "agent memory" category is gaining mindshare fast. sqlite-memory-mcp is not pitched as a 1:1 replacement; it targets a different point in the design space — a local-first, multi-agent, provenance-governed knowledge graph that any MCP client can share, rather than a single-agent built-in. The category risk is real, which is precisely why the governance and cross-agent surface matter.

Convergent evolution: sqlite-memory-mcp vs GBrain

GBrain — Garry Tan's structured knowledge layer for AI agents — launched 2026-04-10. It and sqlite-memory-mcp arrived independently at the same architectural conclusions: local-first storage, hybrid lexical + vector search fused via Reciprocal Rank Fusion, rule-based zero-LLM entity extraction, and a memory-consolidation cycle (GBrain calls it dream, sqlite-memory-mcp calls it reflect). When two solo founders converge on the same architecture, the design space is real.

The two projects ship different bets for different deployments. Public git history establishes that sqlite-memory-mcp's hybrid search shipped on 2026-03-18 (commit feat(search): add hybrid semantic search via sqlite-vec + RRF fusion) — twenty-three days before GBrain's first public release.

| Axis | GBrain | sqlite-memory-mcp | |---|---|---| | Initial public release | 2026-04-10 | 2026-03-01 (v0.1.0, 40-day lead) | | Hybrid search (BM25 + vector + RRF) | shipped 2026-04-10 | shipped 2026-03-18 (23-day lead) | | Storage primitive | Markdown files in git + PGLite (embedded Postgres) + pgvector | Single SQLite file (FTS5 + sqlite-vec) + bridge git repo | | Infrastructure footprint | Postgres runtime + git remote + LLM API | Single binary, single file, optional local embeddings | | Embeddings | OpenAI API (network call per page write) | sentence-transformers, fully local | | Memory consolidation | "dream cycle" (uses LLM) | reflect_audit Phase 0.5 — deterministic SQL, no LLM cost | | Per-candidate review | atomic store-level output | per-row accept / reject / defer with apply snapshots | | Cross-machine sync | git remote of the brain repo | bridge JSON + per-field LWW-Register CRDT; conflict/recovery regressions and operational discipline address no-resurrect / no-data-loss failure modes without claiming an absolute data-loss guarantee | | Source of truth | Markdown (human-readable) | SQLite + JSON bridge exports (machine-portable) | | Air-gapped / regulated deployment | blocked by OpenAI embedding requirement | fully supported (no external network in hot path) | | Companion

…

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: RMANOV
• Source: RMANOV/sqlite-memory-mcp
• License: MIT

Install and usage instructions live in the source repository linked above.