Generated banner for Memorizer
Generated logo for Memorizer

Memorizer

Memory serverOfficial Petabridge project

Created by Dario Griffo

Published in petabridge/memorizer. Publisher page

221 GitHub stars

What it is

Vector-search powered agent memory MCP server
— the description by Dario Griffo

AutoGineer overview, from the brain’s own files

Memorizer is a dedicated memory service designed to give AI agents persistent, long-term storage capabilities. It functions as an MCP server, allowing agents to store, retrieve, and semantically search through structured memories. Built on .NET and PostgreSQL with the pgvector extension, it supports advanced features like versioning, audit trails, relationship mapping for knowledge graphs, and workspace-based organization. It includes a web-based UI for manual management and provides a robust framework for agents to proactively manage their own knowledge base, ensuring that insights and context are preserved across sessions.

How it works

Memory model: Hybrid

AutoGineer overview, from the brain’s own files

Memorizer runs as a service that connects to an AI agent via the Model Context Protocol. It stores data in a PostgreSQL database, utilizing vector embeddings for semantic similarity searches. The system organizes information into workspaces and projects, supports metadata tagging, and tracks version history for all memory entries. Agents interact with the service through a set of defined tools for CRUD operations, metadata updates, and relationship creation, enabling the construction of an interconnected knowledge graph.

Folders
FolderRoleFiles
.githubagent-config4
docsdocs37
scriptsscripts3
srcsource-code195
.configfolder1

The agent writes

Requirements

Databases: PostgreSQL

Works with: Claude Code, OpenCode, Devin (ex-Windsurf)

Set it up

  1. Not scanned by AutoGineerThe author’s README also describes installing it with Docker Compose. Read its install section: AutoGineer did not scan that path. https://github.com/petabridge/memorizer/blob/d3e90fa8d6b50254d65a3ffa3acc35e0204c5c90/README.md#-quick-start-public-image
  2. Created by Dario Griffo. Published in petabridge/memorizer. Licence: MIT License.

Usage

AutoGineer overview, from the brain’s own files

  • Connects to AI agents via the Model Context Protocol (MCP) to provide persistent memory.
  • Enables semantic search to retrieve relevant context based on task descriptions.
  • Supports proactive memory management where agents store, update, and relate information autonomously.
  • Provides a web interface for human users to manage, audit, and organize memory entries.
  • Facilitates knowledge graph construction by creating explicit relationships between memory nodes.
“Search for previous instructions on how to configure the build pipeline.”
The agent queries the memory server using semantic similarity to find relevant 'how-to' notes and returns the specific configuration steps.
“Store this new insight about the project architecture as a reference.”
The agent saves the markdown content to the memory server with appropriate tags and metadata for future retrieval.
“Link this new task to the related project requirements memory.”
The agent creates a relationship edge between the new memory ID and the existing requirements memory ID.

Documentation by Dario Griffo

Memorizer

Image: Docker Pulls Image: GitHub License Image: GitHub Actions Workflow Status Image: GitHub Release

Memorizer is a .NET-based service that allows AI agents to store, retrieve, and search through memories using vector embeddings. It leverages PostgreSQL with the pgvector extension to provide efficient similarity search capabilities.

Image: Memorizer - Memory List

Key features:

  • Workspaces & Projects - Organize memories into hierarchical workspaces and projects with status tracking

  • Store structured memories with vector embeddings

  • Retrieve memories by ID

  • Semantic search through memories using vector similarity

  • Filter search results using tags

  • Edit memory content with automatic versioning and change tracking

  • Update memory metadata (title, type, tags, confidence) independently

  • Revert memories to previous versions with full audit trail

  • Create relationships between memories to form knowledge graphs

  • Web UI for manually adding, editing, deleting, viewing memories, and managing versions

  • Provider Settings - Configure embedding and LLM providers through the UI (Ollama, OpenAI, and compatible APIs)

  • MCP (Model Context Protocol) integration for easy use with AI agents

  • Light & Dark theme support

Image: Memorizer - Workspace Detail

Technologies

  • .NET 10.0

  • PostgreSQL with pgvector extension

  • Model Context Protocol (MCP)

  • ASP.NET Core

  • Akka.NET for background jobs, such as re-embedding memories if you change algorithms

  • Npgsql for PostgreSQL connectivity


📖 Documentation


Installation with Docker

🐳 Quick Start (Public Image)

The easiest way to get started is using the pre-built Docker image and our docker-compose.yml file:

docker-compose up -d

This will:

View the Memorizer Web UI on http://localhost:5000.

🚀 Local Development Builds

If you want to build and run from source:

Prerequisites
  • Docker and Docker Compose

  • .NET 10.0 SDK

1. Build and Publish Local Container
# From solution root directory
# Build and publish the .NET container
dotnet publish -c Release /t:PublishContainer

This creates a container image named memorizer:latest.

2. Start Infrastructure and Application
docker-compose -f docker-compose.local.yml up -d

This starts the same services but uses your locally built image.


Upgrading to Memorizer 2.0

NOTE
The upgrade from Memorizer 1.x to 2.0 is designed to work automatically. All schema migrations run on startup and have been thoroughly tested. Your existing memories will be preserved and continue to work as expected.

CAUTION
We recommend backing up your database before upgrading, as a standard best practice. Memorizer 2.0 runs automatic schema migrations on startup that alter tables and add new columns. While we've tested these migrations extensively, having a backup ensures you can recover in the unlikely event that something goes wrong.

Backup Instructions

NOTE
The container names below (e.g., memorizer-postgres) are based on the default docker-compose.yml. If you've customized your Docker Compose file, adjust the container name accordingly.

Before pulling the new Memorizer 2.0 image, create a PostgreSQL dump of your existing database:

# Create a full database backup
docker exec postgmem-postgres pg_dump -U postgres postgmem > memorizer-backup-$(date +%Y%m%d).sql

# Or use pg_dump with compression
docker exec postgmem-postgres pg_dump -U postgres -Fc postgmem > memorizer-backup-$(date +%Y%m%d).dump

To restore from a backup if needed:

# Restore from SQL dump
docker exec -i postgmem-postgres psql -U postgres postgmem < memorizer-backup-20250207.sql

# Or restore from compressed dump
docker exec -i postgmem-postgres pg_restore -U postgres -d postgmem memorizer-backup-20250207.dump
Updating
# make sure you have created a backup before starting here
git pull
docker-compose down
docker-compose pull memorizer
docker-compose up -d
Breaking Changes in 2.0
  • MCP endpoint moved from / to /mcp. Update your MCP client configurations from http://localhost:5000 to http://localhost:5000/mcp.

  • Web UI moved from /ui to /. The Web UI is now at the root path.

  • New database tables: Workspaces, projects, provider settings, data migrations, and archetype tracking are added automatically on first startup.

  • Existing memories are preserved: All your V1 memories will continue to work. They will appear as "Unfiled" until you organize them into workspaces and projects.

After Upgrading

TIP
Once the upgrade is complete, ask your AI agent to suggest workspaces and projects to organize your existing memories into. Memorizer 2.0's workspace and project system helps you keep memories structured and easy to find - and your agent can analyze your existing memories to recommend a good organizational scheme.


🔌 MCP Configuration Example

To use Memorizer with any MCP-compatible client, add the following to your configuration (e.g., mcp.json):

{
  "memorizer": {
    "url": "http://localhost:5000/mcp"
  }
}

This uses the modern Streamable HTTP transport (MCP spec 2025-03-26+). Note that the MCP endpoint is at /mcp (changed from / in 2.0).


🖥️ Web UI

Memorizer includes a web-based user interface for managing memories through your browser.

Access the Web UI

Once the application is running (via docker-compose up -d), you can access the Web UI at:

http://localhost:5000/

Features
  • Memory Management: Create, view, edit, and delete memories with full CRUD operations

  • Version Control: View version history, compare versions with visual diffs, and revert to previous versions

  • Search & Filter: Search memories using semantic similarity and filter by tags

  • Statistics Dashboard: View memory counts, tag distributions, and system statistics

  • MCP Configuration: Get the MCP configuration JSON for connecting clients at /mcp-config

The Web UI provides a user-friendly interface for all Memorizer functionality, making it easy to manage your AI agent's memory without needing to use the MCP tools directly.


🧠 Example System Prompt for LLMs

IMPORTANT
⚡ Pro Tip: Add this system prompt to your AGENT.md, Cursor Rules files, or any AI agent configuration! This will dramatically improve how often and effectively your LLM uses the Memorizer service for persistent memory management.

You have access to a long-term memory system via the Model Context Protocol (MCP) at the endpoint memorizer. Use the following tools:

Storage & Retrieval:

  • store: Store a new memory. Parameters: type, text (markdown), source, title, tags, confidence, relatedTo (optional, memory ID), relationshipType (optional).

  • searchMemories: Search for similar memories using semantic similarity. Parameters: query, limit, minSimilarity, filterTags.

  • get: Retrieve a memory by ID. Parameters: id, includeVersionHistory, versionNumber.

  • getMany: Retrieve multiple memories by their IDs. Parameter: ids (list of IDs).

  • delete: Delete a memory by ID. Parameter: id.

Editing & Updates:

  • edit: Edit memory content using find-and-replace (ideal for checking off to-do items, updating sections). Parameters: id, old_text, new_text, replace_all.

  • updateMetadata: Update memory metadata (title, type, tags, confidence) without changing content. Parameters: id, title, type, tags, confidence.

Relationships & Versioning:

  • createRelationship: Create a relationship between two memories. Parameters: fromId, toId, type (e.g., 'example-of', 'explains', 'related-to').

  • revertToVersion: Revert a memory to a previous version. Parameters: id, versionNumber, changedBy.

All edits and updates are automatically versioned, allowing you to track changes and revert if needed. Use these tools to remember, recall, edit, relate, and manage information as needed to assist the user.


License

MIT


💖 Attribution

Made with ❤️ by Petabridge

Originally forked from Dario Griffo's postg-mem server

docs/embedding-models.md

Supported Embedding Models

This document provides guidance on choosing and configuring embedding models for Memorizer.

What Are Embedding Models?

Embedding models convert text into dense numerical vectors (embeddings) that capture semantic meaning. These vectors enable similarity search - finding memories that are conceptually related to a query, not just keyword matches.

Memorizer uses these embeddings for:

  • Semantic search: Find memories by meaning, not just exact text

  • Metadata search: Search by title, tags, and type combined

  • Similarity ranking: Order results by relevance

Supported Providers

Memorizer works with any embedding API that follows the Ollama embedding format:

POST /api/embed
{
  "model": "model-name",
  "input": "text to embed",
  "truncate": true
}

Input longer than the model's context window is truncated to fit rather than rejected, so long memories still get an embedding; only the first part of the text (256 tokens for all-minilm) contributes to it. If long memories matter for search, choose a model with a larger context window.

Ollama provides an easy way to run embedding models locally:

# Install Ollama
curl -fsSL https://ollama.ai/install.sh | sh

# Pull an embedding model
ollama pull all-minilm

# Verify it's working
curl http://localhost:11434/api/embed -d '{
  "model": "all-minilm",
  "input": "test"
}'
Other Compatible Providers
  • LocalAI: Self-hosted, OpenAI-compatible API

  • LM Studio: Desktop app with API server mode

  • vLLM: High-performance inference server

Quick Reference Table
ModelDimensionsSizeSpeedQualityBest For
all-minilm38423MBFastGoodGeneral use, limited resources
all-minilm:33m-l12-v2-fp1638466MBFastGoodBetter precision than base
nomic-embed-text768274MBMediumBetterBalanced quality/speed
mxbai-embed-large1024670MBSlowBestMaximum quality
bge-base-en-v1.5768438MBMediumBetterEnglish text
bge-large-en-v1.510241.3GBSlowBestEnglish text, high quality
bge-m310241.2GBSlowBestMultilingual
snowflake-arctic-embed10241.1GBSlowBestRetrieval tasks
qwen3-embedding:0.6b1024639MBFastBetterLightweight multilingual
qwen3-embedding:4b25602.5GBMediumBestHigh quality multilingual
qwen3-embedding:8b40964.7GBSlowState-of-artMaximum quality, code retrieval
Detailed Model Information
ollama pull all-minilm
  • Dimensions: 384

  • Context: 256 tokens

  • Strengths: Very fast, low memory, good general performance

  • Weaknesses: Smaller context window, lower quality on complex queries

  • Use when: Running on limited hardware, need fast responses, memories are short

nomic-embed-text
ollama pull nomic-embed-text
  • Dimensions: 768

  • Context: 8192 tokens

  • Strengths: Long context, good quality, reasonable speed

  • Weaknesses: Larger than minilm, requires more memory

  • Use when: Memories contain longer documents, need better semantic understanding

mxbai-embed-large
ollama pull mxbai-embed-large
  • Dimensions: 1024

  • Context: 512 tokens

  • Strengths: High quality embeddings, good for retrieval

  • Weaknesses: Slower, requires more storage for embeddings

  • Use when: Quality is priority, have adequate compute resources

bge-large-en-v1.5
ollama pull bge-large-en-v1.5
  • Dimensions: 1024

  • Context: 512 tokens

  • Strengths: Excellent quality for English, well-benchmarked

  • Weaknesses: English-only, large model size

  • Use when: English content only, maximum retrieval quality needed

bge-m3
ollama pull bge-m3
  • Dimensions: 1024

  • Context: 8192 tokens

  • Strengths: Multilingual (100+ languages), long context

  • Weaknesses: Slower, large model

  • Use when: Multilingual content, long documents

Qwen3 Embedding Series (State-of-the-Art)

The Qwen3 Embedding series offers state-of-the-art performance, ranking #1 on the MTEB multilingual leaderboard (score 70.58 as of June 2025).

# Lightweight option
ollama pull qwen3-embedding:0.6b

# Balanced option
ollama pull qwen3-embedding:4b

# Maximum quality
ollama pull qwen3-embedding:8b

qwen3-embedding:0.6b

  • Dimensions: Up to 1024 (configurable 32-1024)

  • Context: 32K tokens

  • Size: 639MB

  • Use when: Need multilingual support with limited resources

qwen3-embedding:4b

  • Dimensions: Up to 2560 (configurable 32-2560)

  • Context: 40K tokens

  • Size: 2.5GB

  • Use when: Balanced quality and resource usage

qwen3-embedding:8b

  • Dimensions: Up to 4096 (configurable 32-4096)

  • Context: 40K tokens

  • Size: 4.7GB

  • Use when: Maximum quality, code retrieval, complex semantic search

Key strengths of Qwen3 Embedding:

  • 100+ language support including programming languages

  • Exceptional code retrieval performance

  • Very long context windows (32K-40K tokens)

  • Configurable output dimensions

  • State-of-the-art benchmark scores

Configuration

Configure your embedding model in appsettings.json:

{
  "Embeddings": {
    "ApiUrl": "http://localhost:11434",
    "Model": "all-minilm",
    "Timeout": "00:01:00"
  }
}
Configuration Options
SettingDescriptionDefault
ApiUrlURL of the embedding APIhttp://localhost:11434
ModelModel name to useRequired
TimeoutRequest timeout00:01:00
Environment Variables

You can also configure via environment variables:

export Embeddings__ApiUrl=http://localhost:11434
export Embeddings__Model=nomic-embed-text
export Embeddings__Timeout=00:02:00

Changing Models

Same Dimension Models

If you switch to a model with the same dimensions (e.g., all-minilm to another 384D model), no migration is needed. Just update the config and restart.

Different Dimension Models

If the new model has different dimensions, you must run a migration:

  1. Update Embeddings:Model in configuration

  2. Restart Memorizer - you'll see a warning banner

  3. Navigate to Tools > Dimension Migration

  4. Click Start Dimension Migration

  5. Wait for all embeddings to regenerate

See Embedding Migration for detailed migration instructions.

Migration Time Estimates

Migration time depends on:

  • Number of memories

  • Embedding model speed

  • Hardware resources

Rough estimates for 1,000 memories:

ModelApproximate Time
all-minilm~2-5 minutes
nomic-embed-text~5-10 minutes
mxbai-embed-large~10-20 minutes

Choosing a Model

Decision Flowchart
Start
  │
  ▼
Do you have GPU acceleration?
  │
  ├─ No ──► all-minilm (384D) or qwen3-embedding:0.6b (1024D)
  │
  ▼ Yes
  │
Is state-of-the-art quality critical?
  │
  ├─ Yes ──► qwen3-embedding:8b (4096D)
  │
  ▼ No
  │
Is multilingual support needed?
  │
  ├─ Yes ──► qwen3-embedding:4b (2560D) or bge-m3 (1024D)
  │
  ▼ No
  │
Are your documents long (>500 words)?
  │
  ├─ Yes ──► nomic-embed-text (768D)
  │
  ▼ No
  │
Is code retrieval important?
  │
  ├─ Yes ──► qwen3-embedding:4b (2560D)
  │
  ▼ No
  │
nomic-embed-text (768D)
Recommendations by Use Case
Use CaseRecommended ModelWhy
Personal notesall-minilmFast, works on any hardware
Code snippetsqwen3-embedding:4bExcellent code retrieval, programming language support
Documentationnomic-embed-textLong context support, good balance
Research papersbge-large-en-v1.5High quality retrieval for English
Multilingual contentqwen3-embedding:4b100+ languages, state-of-the-art quality
Maximum accuracyqwen3-embedding:8b#1 on MTEB leaderboard
Limited resourcesqwen3-embedding:0.6bGood quality at small size

Storage Considerations

Higher dimension models require more database storage:

DimensionsStorage per Memory10,000 Memories
384~1.5 KB~15 MB
768~3 KB~30 MB
1024~4 KB~40 MB
2560~10 KB~100 MB
4096~16 KB~160 MB

Note: These are estimates for the embedding vectors only. Actual storage includes text content, metadata embeddings, and indexes.

Performance Tuning

For Faster Embedding Generation
  1. Use GPU acceleration if available

  2. Choose a smaller model (all-minilm)

  3. Increase timeout for batch operations

  4. Run Ollama with OLLAMA_NUM_PARALLEL=4 for concurrent requests

For Better Search Quality
  1. Use a larger model (mxbai-embed-large, bge-large)

  2. Ensure model context covers your typical memory length

  3. Use descriptive titles and tags (they're embedded separately)

Troubleshooting

"Model not found"
# List available models
ollama list

# Pull the model you need
ollama pull model-name
"Embedding API timeout"

Increase the timeout in configuration:

{
  "Embeddings": {
    "Timeout": "00:05:00"
  }
}
"Dimension mismatch detected"

You've changed to a model with different output dimensions. See Embedding Migration.

Slow embedding generation
  • Check if Ollama is using GPU: ollama ps

  • Try a smaller model

  • Ensure adequate system memory

External Resources

260 files · 244 not served here

Advantages

  • Provides persistent, long-term memory that survives agent session resets. evidence: README.md
  • Supports semantic search through vector embeddings, allowing for context-aware retrieval. evidence: README.md
  • Includes full versioning and audit trails for all memory modifications. evidence: README.md
  • Allows for the creation of knowledge graphs by linking related memories. evidence: README.md

Limitations

  • Requires external infrastructure including PostgreSQL with pgvector and an embedding provider. evidence: README.md
  • Requires manual configuration of MCP clients to point to the correct endpoint. evidence: README.md
  • Upgrades may require database backups and potential schema migrations. evidence: README.md

Security

Risk level: No risk found

This brain runs

This brain runs nothing: AutoGineer found no hooks, scripts, plugin code or MCP servers in its files.

Attribution and licence

Created by
Dario Griffo
Publisher
Petabridge (Official Petabridge project)
Source
petabridge/memorizer · commit d3e90fa
Licence
MIT License (files served here)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Dario Griffo or Petabridge.

Install from source

244 of its files are not served here, so there is no ZIP. petabridge/memorizer at d3e90fa