← Back to directory
M

Memory Vault

Community
Self-hosted AI memory database with hybrid search, MCP tools, and a knowledge graph.
Category
Database #28 of 58
Stars
★ 65 Popular
Transport
stdio (local process) · SSE
Runtime
Python 3.11+ · Docker
Credentials
No credential needed
License
MIT
Last commit
Tools
6
56FMRS · C

Memory Vault is a self-hosted, MIT-licensed AI memory layer that bundles PostgreSQL + pgvector hybrid search, MCP-native tools, a knowledge graph, and local LLM chat around the promise that your data never leaves your machine. It is database-backed memory infrastructure rather than a filesystem note tool, aimed at individual developers who are comfortable running Postgres and who want to use memory through MCP, REST, or the dashboard as equal interfaces. Caveats to weigh: v1.0 is single-instance, NER is English-only, the HTTP/SSE transport is off by default and ships without encryption, and team features remain a planned PRO tier; the project is maintained by a single author, so response times are not guaranteed.

Strongest · Documentation 14/20 Weakest · Reliability 9/20

Reliability
9/20
Security and permissions
12/20
Maintenance
11/20
Documentation
14/20
Setup experience
10/20
Why each score
Reliability 9/20
Static evidence is limited to README plus server.json; no source code, tests, or CI workflow files were supplied, so the calibration cap of 12 applies. Positive signals: the manifest declares an OCI image at 1.5.0 over stdio, and the README documents six MCP tools (recall, remember, forget, purge_forgotten, move_memory, memory_status) and two resources (memory://spaces, memory://stats), plus module launch commands and named startup failures (ModuleNotFoundError, spaCy E050), which shows the author has thought about init failure paths. Deductions: the manifest requires four env vars but declares no preflight validation of database reachability, the pgvector extension, or the spaCy model; the README's Features section claims 'four tools' while the Tools table lists six, an internal contradiction, and tool-vs-behavior parity cannot be verified statically; no tests or CI evidence; purge_forgotten is irreversible yet no confirmation mechanism is described. Scored 9: the happy path is plausible, but error surfaces and dependency controllability are thinly evidenced.
Security and permissions 12/20
No red line is triggered: no static evidence of malware, credential theft, covert exfiltration, or fabricated identity, and every credential in the install examples is a placeholder (memory_vault, mv_your-token-here), not a real secret, so the 0-4 band does not apply. Positive evidence: DB_PASSWORD is flagged isSecret in the manifest; the HTTP/SSE MCP transport is off by default and requires MCP_HTTP_ENABLED=true; the README states API_AUTH_ENABLED=false does not open the MCP transport and unauthenticated calls still get 401; a Host-header allowlist returning HTTP 421 mitigates DNS rebinding; it advises binding to a LAN address and fronting with a reverse proxy/TLS and discloses there is no transport encryption; tokens are revocable and shared between REST and MCP via one table; the diagnose bundle scrubs tokens and passwords. Deductions: API_HOST defaults to 0.0.0.0 and API_CORS_ORIGINS defaults to '*'; the dashboard stores bearer tokens in localStorage, an XSS surface; forget is a soft delete but purge_forgotten is a permanent one with no documented confirmation or dry-run; a single read/write DB user means no least-privilege split; single-instance with no multi-tenant isolation; the Host check, rate limiting, and redaction implementations cannot be inspected. Scored 12: main risks are visible and deliberately narrowed, but confirmation flows, least privilege, and verifiability are incomplete.
Maintenance 11/20
Evidence: an explicit MIT license; SECURITY.md provides a private vulnerability channel via email; CONTRIBUTING.md, CODE_OF_CONDUCT.md (Contributor Covenant v2.1), a threat-model doc, and issue/PR templates are all referenced; the README reports M1-M7 shipped, v1.0 released 2026-05-07, with a semver promise and additive-only migrations within v1.x; ACKNOWLEDGMENTS credits 20+ external issues across the v1.0.7-v1.0.10 window, implying a real response loop; the manifest version 1.5.0 aligns with README-mentioned v1.5.0 changes (per-query ef_search, index warming). Deductions: source and CHANGELOG are unreadable, so commit cadence, dependency-update policy, and actual issue-response latency cannot be verified; a self-described single maintainer with no governance or succession plan; 11 open issues with no visible triage state; no evidence of a dependency pinning strategy across sentence-transformers, spaCy, pgvector, FastMCP, and React 19; the PRO/OSS boundary remains a plan. Scored 11: active with a sound license and security channel, but governance and version-management details have gaps.
Documentation 14/20
The evidence is layered and substantial: Quick Start with both Docker and No-Docker paths; uv and pip+venv installs; Claude Code configuration at project scope (.mcp.json) and global scope (~/.claude/.mcp.json plus enabledMcpjsonServers) alongside Claude Desktop; the Docker-specific DB_HOST=127.0.0.1 guidance; a full remote HTTP/SSE section covering the flag, URL, Bearer header, MCP_HTTP_ALLOWED_HOSTS semantics including that the list replaces rather than extends the default, and what 421 means; a REST endpoint table; auth and token lifecycle; a config-variable table; performance tuning (maintenance_work_mem); a dedicated Limitations section (English-only NER, no alias merging, no re-extraction on edit, single-instance, LM Studio only); an FAQ; troubleshooting for ModuleNotFoundError, spaCy E050, `claude --debug mcp`, CORS, and blocked localStorage; and a bug workflow built on X-Request-ID plus `memory-vault diagnose`. Deductions: the Features section saying 'four tools' directly contradicts the six-row Tools table, an internal inconsistency; tool parameter signatures (recall/remember fields, limit, space semantics) are absent beyond one-line summaries; Local LLM Chat requires LM Studio with a model blocklist justified only narratively and no version floor; cost/resource figures are approximate; and there are no example tool-call responses. Scored 14: install, auth, limits, and troubleshooting are well covered, but parameter-level reference and internal consistency have gaps.
Setup experience 10/20
Evidence: the Docker path is three commands (git clone, cd, docker compose up -d) with automatic migrations, a dashboard at http://localhost:8000, and volume-persisted data; the No-Docker path enumerates Python 3.11+, Postgres 16 + pgvector, and full uv or pip+venv sequences (uv sync, spaCy model download, .env, migrate, status); copy-pasteable JSON config blocks are given per client, distinguishing Claude Code project vs global scope and Claude Desktop; the Docker DB_HOST difference is called out; Windows users are routed to docs/windows.md with a WSL2 recommendation. Deductions: every deployment requires an external Postgres 16 + pgvector instance, a heavy prerequisite, and the manifest marks DB_HOST, DB_PORT, DB_NAME, DB_USER, and DB_PASSWORD all required, so any one missing blocks startup; the spaCy model is a separate download whose omission yields OSError [E050]; global-scope MCP requires hand-editing ~/.claude/settings.json, which is easy to miss; no sample .env body is shown (only a pointer to .env.example); no offline/GPU or image-verification guidance; and no minimal connectivity check beyond memory_status and `claude mcp list`. With the static cap of 15 and evidence drawn only from unverified README/manifest text, scored 10: the path is clear but manual steps plus external-database coupling make first-run connection fragile.

Static review · not runListed 2026-09-10

Read the FMRS scoring method →

Fit and risk

What it can accessConnects to a database

Best for

  • Individual developers who want memory data fully self-hosted and never sent to the cloud
  • Users already comfortable operating PostgreSQL
  • People who want cross-session memory in Claude Desktop or Claude Code
  • Builders layering memory under their own AI tooling without maintaining a separate vector database (single instance)

Not for

  • Organizations needing multi-user or multi-tenant team collaboration (v1.0 is single-instance; team features are planned PRO)
  • Users who want a zero-ops hosted service
  • Projects requiring multilingual entity extraction (NER is English-only)
  • Anyone unwilling to run and maintain PostgreSQL
  • Deployments expecting transport encryption to come from the server itself (you must add a reverse proxy or tunnel)

Required permissions

  • Read/write access to the PostgreSQL database (DB_USER needs read/write on the memory vault database)
  • The database password (DB_PASSWORD is a secret value)
  • In stdio mode, a local process that reads environment variables and connects to the database
  • When HTTP/SSE is enabled, a listening port plus bearer token validation on every request
  • The dashboard stores its bearer token in browser localStorage

Risks and side effects

  • With stdio, database credentials sit in plaintext in the client config's env block
  • The HTTP/SSE transport has no transport encryption of its own; tokens travel in a header, so put TLS in front of it
  • Publishing the container port on 0.0.0.0 reaches the whole network
  • API_AUTH_ENABLED=false only opens the REST API (the MCP transport still returns 401) and is a local-development convenience only
  • Known knowledge-graph limits: no fuzzy entity matching (PostgreSQL and Postgres stay separate), no re-extraction on edit, and one name can appear as both a Person and a Project entity
  • Single-maintainer project — reviews and responses depend on the maintainer's available time

Setup

Before you start

Runtime:Python 3.11+ · Docker

DB_HOST required Hostname of the Postgres+pgvector instance; use 127.0.0.1 or host.docker.internal with Docker.
DB_PORT required Postgres port, defaults to 5432.
DB_NAME required Postgres database name, defaults to memory_vault.
DB_USER required Postgres user with read/write access to the memory vault database.
DB_PASSWORD requiredsecret Password for DB_USER; you set it yourself.

Option 1 (Docker, recommended): clone the repository, cd into it, and run docker compose up -d. Migrations run automatically on first start; verify with docker compose exec app memory-vault status. The dashboard is at http://localhost:8000.

Option 2 (no Docker): requires Python 3.11+, PostgreSQL 16 with the pgvector extension, and uv (or pip + venv). Run uv sync, then uv run python -m spacy download en_core_web_sm, then cp .env.example .env and fill in your PostgreSQL credentials, then uv run memory-vault migrate and uv run memory-vault status.

Configure your MCP client: complete the no-Docker setup above first so the memory_vault package is installed, then add the server block shown in install_config to your project's .mcp.json in Claude Code (or ~/.claude/.mcp.json), filling in DB_HOST, DB_PORT, DB_NAME, DB_USER, and DB_PASSWORD. For global availability, also add memory-vault to enabledMcpjsonServers in ~/.claude/settings.json. Verify with claude mcp list — it should show connected. For Claude Desktop, add the same block via Settings → Developer → Edit Config and restart.

Docker users: the MCP server runs on the host (not inside Docker) and connects over the exposed port, so set DB_HOST to 127.0.0.1 and make sure port 5432 is exposed in docker-compose.yml. For remote access over HTTP/SSE, set MCP_HTTP_ENABLED=true; the transport mounts at /api/mcp and clients connect to http://<host>:8000/api/mcp/sse with a bearer token created via memory-vault token create. Declare allowed hostnames with MCP_HTTP_ALLOWED_HOSTS (the list replaces the default, which covers localhost and 127.0.0.1 only).

claude_desktop_config.json
{
  "mcpServers": {
    "memory-vault": {
      "command": "/path/to/memory-vault/.venv/bin/python",
      "args": ["-m", "memory_vault.mcp"],
      "env": {
        "DB_HOST": "localhost",
        "DB_PORT": "5432",
        "DB_NAME": "memory_vault",
        "DB_USER": "memory_vault",
        "DB_PASSWORD": "memory_vault"
      }
    }
  }
}

Shown for Claude Desktop. Other clients may use a different file or key (VS Code uses "servers") — the configurator below converts it.

.vscode/mcp.json
{
  "servers": {
    "memory-vault": {
      "command": "/path/to/memory-vault/.venv/bin/python",
      "args": [
        "-m",
        "memory_vault.mcp"
      ],
      "env": {
        "DB_HOST": "localhost",
        "DB_PORT": "5432",
        "DB_NAME": "memory_vault",
        "DB_USER": "memory_vault",
        "DB_PASSWORD": "memory_vault"
      }
    }
  }
}

Goes in your project's .vscode/mcp.json (VS Code uses a "servers" key).

Terminal
claude mcp add memory-vault -e DB_HOST=localhost -e DB_PORT=5432 -e DB_NAME=memory_vault -e DB_USER=memory_vault -e DB_PASSWORD=memory_vault -- /path/to/memory-vault/.venv/bin/python -m memory_vault.mcp

Run it in a terminal; replace any <…> placeholders with your own values first.

Check that it works

Run `claude mcp list` in Claude Code and confirm memory-vault shows connected, or ask "Use memory_status to check the memory system" to confirm the tools are available.

Troubleshooting

  1. ModuleNotFoundError on startup: the virtual environment isn't installed; re-run uv sync (or pip install -e .) in the repo directory
  2. OSError: [E050] on startup: the spaCy language model isn't installed; re-run python -m spacy download en_core_web_sm
  3. Server shows failed in Claude Code: run claude --debug mcp to see the server's error output
  4. Server connects but tools are unavailable: confirm memory-vault is listed in enabledMcpjsonServers in ~/.claude/settings.json
  5. Connection refused with Docker running: use DB_HOST 127.0.0.1 instead of localhost
  6. Remote client gets 421 Misdirected Request: the hostname it used is not in MCP_HTTP_ALLOWED_HOSTS (the list replaces the default, so keep localhost:* if local clients are still needed)
  7. Dashboard prompts for a token on every reload: the browser is blocking localStorage (private mode or strict cookie settings)
  8. 401 on every dashboard request: the token was revoked or API_AUTH_ENABLED changed; create a fresh token and paste it in
  9. Before filing a bug, run docker compose exec app memory-vault diagnose to build a diagnostic bundle (tokens and passwords are auto-scrubbed, but review it first)
  10. Include the X-Request-ID response header in bug reports so the same request can be found in the structured JSON logs

Things to try

Once connected, you can ask your AI assistant things like:

  • Use memory_status to check the memory system.
  • Remember that we chose Redis for the session cache.
  • Recall everything about hybrid search.
  • Move this memory to the default space.

Tools 6

recall read-only
Search memories with hybrid search (vector + full-text + RRF).
remember writes
Store a new memory — auto-classified and embedded.
forget destructive
Soft-delete a memory by chunk ID.
purge_forgotten destructive
Permanently delete memories forgotten more than N days ago.
move_memory writes
Move a memory to another space, rebuilding its graph entries.
memory_status read-only
Database health, chunk counts, embedding model info.

Use cases

Let Claude remember project decisions, notes, and already-solved problems across sessions
Run hybrid semantic plus keyword retrieval over a large local corpus of notes or documents
Ask your own memory vault questions through a local LM Studio model with sources shown for verification
Integrate persistent memory into your own AI application via the REST API or dashboard
Explore automatically extracted entities and relationships in the knowledge graph on CPU only

Supported clients

Claude Desktop
Claude Code

Listed from the project's documentation, not tested by this site.

Overview

Memory Vault is a local-first AI memory layer built on self-hosted PostgreSQL 16 + pgvector. Vector embeddings, full-text indexes, and relational data all live in one database, so there is no separate vector store to keep in sync; hybrid search combines vector similarity with PostgreSQL full-text search and merges the ranked lists using Reciprocal Rank Fusion (RRF).

It exposes six MCP tools to Claude (recall, remember, forget, purge_forgotten, move_memory, memory_status) so memories can be read and written during any session. The same memory layer is also reachable through a FastAPI REST API and a React dashboard with six pages (Chat, Search, Browse, Graph, Ingest, Stats); MCP, REST, the CLI, and your own apps are treated as equal first-class clients. The knowledge graph extracts entities with spaCy's en_core_web_sm model and derives related_to edges from co-occurrence, all on CPU with no external LLM or API calls.

The project is MIT licensed and maintained by MihaiBuilds as a single-maintainer project. Embeddings default to all-MiniLM-L6-v2 (384-d, CPU). Local LLM chat supports LM Studio in v1.0 and always shows the exact memory chunks each answer was grounded in. MCP defaults to stdio transport; HTTP/SSE transport must be explicitly enabled with MCP_HTTP_ENABLED=true and always requires a bearer token.

Similar servers

Source revision d0d6b86b5f37 Data synced 2026-10-19 Read the FMRS scoring method