Servidores de memória MCP: SynaBun vs mem0 vs Letta vs Zep

Já existe meia dúzia de servidores de memória de IA sérios por aí, e as páginas de marketing não ajudam você a escolher. Cada projeto destaca o que faz bem e pula o que não faz.

Este post é a versão honesta. Eu criei um deles (o SynaBun), então sou parcial — e vou avisar toda vez que essa parcialidade aparecer. Se algo aqui estiver errado, me chame no Discord e eu corrijo.

Os quatro servidores

Estou comparando quatro projetos que têm a mesma função central — dar a um agente de IA para programação memória persistente entre sessões —, mas fazem escolhas de arquitetura radicalmente diferentes.

• SynaBun — local-first, nativo em MCP, 157 ferramentas (memória + assistente + navegador + redes sociais + quadro branco + loops), Apache 2.0
• Mem0 — cloud-first com opção self-hosted, compatível com MCP, 6 ferramentas, Apache 2.0
• Letta (antigo MemGPT) — cloud-first, framework de agentes com blocos de memória estruturados, Apache 2.0
• Zep — cloud-first, camada de grafo de conhecimento, núcleo Apache 2.0 + Cloud comercial

Também existem o OpenMemory (uma variante local-first compatível com o Mem0) e o Memory Keeper, mas eles se sobrepõem bastante aos quatro acima.

Matriz de decisão rápida

O resto deste post é a versão longa.

Matriz de recursos

SynaBun

Proposta: o servidor MCP que tem de tudo. A memória é uma das 157 ferramentas, não a única.

Arquitetura: servidor MCP em Node + SQLite (busca por palavra-chave com FTS5 e vetores armazenados como BLOBs) + embeddings locais. A recuperação é híbrida por padrão desde a 2.0.0. Inclui uma interface 3D em React ("Neural Interface") para navegar pela memória, uma API REST em Express, hooks do Claude Code e um Schedules Studio para loops acionados por cron. As ferramentas de navegador encapsulam o Playwright.

Embedding: all-MiniLM-L6-v2 (local, 22MB, 384 dimensões). O raciocínio detalhado está aqui.

Pontos fortes:

• Uma única instalação traz memória, um assistente que conhece a memória e despacha workers, navegador, extração de redes sociais, loops autônomos, bots do Discord, geração de imagem e vídeo com o Leonardo.ai e 30 ferramentas do Google Search Console (nenhuma delas exige chave de API).
• Totalmente local-first. Nenhum recurso exige conta na nuvem.
• Suporte de primeira classe a Claude Code, Codex, OpenCode e Gemini.
• O modelo de memória por categorias (categorias pai/filha, etiquetas de projeto, pontuação de importância) reflete bem como desenvolvedores organizam o conhecimento na prática.

Pontos fracos:

• Mais recursos significam mais coisas para aprender. Se você só quer memória, é exagero.
• As ferramentas de navegador e de redes sociais exigem uma instância do Chrome com interface gráfica, o que complica a configuração em servidores headless.
• Não há opção gerenciada na nuvem. Quem roda é você.

Aviso de parcialidade: eu criei este. Todos os outros servidores deste post são coisas que avaliei antes de decidir escrever o meu.

Quando escolher: você desenvolve sozinho, quer um único servidor MCP que faça tudo e não se importa de hospedar por conta própria.

Mem0

Proposta: o líder da categoria de memória de IA. É ao mesmo tempo um SaaS hospedado e uma biblioteca open source.

Arquitetura: biblioteca Python + API REST + nuvem opcional. Armazena fatos (extraídos das conversas) no Qdrant e metadados estruturados no Postgres. A "camada inteligente" tenta deduplicar e atualizar memórias em vez de só acrescentar.

Embedding: OpenAI text-embedding-3-small por padrão. Dá para trocar na configuração.

Pontos fortes:

• A maior base de usuários da categoria de memória de IA. Muitas integrações, muita documentação.
• Atualizações "inteligentes" de memória — se um fato novo contradiz um antigo, o Mem0 tenta fazer a fusão dos dois.
• Um serviço hospedado na nuvem dispensa configuração se você não quiser hospedar por conta própria.
• Integrações bem testadas com LangGraph, LlamaIndex, AutoGen.

Pontos fracos:

• O self-hosted funciona, mas exige rodar Qdrant + Postgres + a API do Mem0. Não é tão plug-and-play quanto o SQLite.
• A versão em nuvem exige enviar seus dados para os servidores do Mem0. Para alguns times, isso é inegociável.
• 6 ferramentas MCP — camada de memória pura, sem ferramentas adjacentes.
• A deduplicação "inteligente" de memória às vezes apaga contexto que você queria manter. Dá para ajustar, mas dá trabalho.

Quando escolher: você quer um serviço gerenciado de memória na nuvem, com um painel bem-acabado e uma comunidade grande.

Letta (antigo MemGPT)

Proposta: memória como um objeto estruturado dentro de um framework de agentes. Construído em torno do padrão de "gerenciador de contexto" do paper original do MemGPT.

Arquitetura: framework de agentes em Python com três níveis de memória — core (sempre no contexto), archival (com busca vetorial) e recall (histórico do chat). O próprio agente decide quando promover ou rebaixar memórias entre os níveis, por chamadas de ferramenta.

Embedding: OpenAI por padrão, configurável.

Pontos fortes:

• O modelo de memória estruturada é realmente bem projetado. "Core memory" para persona e preferências, "archival" para fatos de longo prazo, "recall" para o histórico do chat: uma separação limpa.
• Stack Docker que você pode hospedar por conta própria. Funciona offline se você trocar o provedor de LLM.
• O paper original do MemGPT acumula citações acadêmicas há dois anos. Linhagem de pesquisa de verdade.
• SDK de agentes integrado, caso você queira lançar um produto de IA voltado para o cliente.

Pontos fracos:

• Mais pesado que os outros. Postgres + API do Letta + o runtime do agente.
• Projetado para aplicações completas de agentes, não para "encaixar uma camada de memória na minha sessão do Claude Code".
• O suporte a MCP é via wrapper — não é nativo.
• Os blocos de memória estruturada exigem decisões de schema logo de início, que podem ser difíceis de migrar depois.

Quando escolher: você está construindo um produto de IA voltado para o cliente em que a memória precisa de níveis estruturados, e quer um framework de agentes que já traga isso pronto.

Zep

Proposta: grafo de conhecimento + memória vetorial. Acompanha entidades, relações e fatos ao longo do tempo, não só texto não estruturado.

Arquitetura: Postgres + Neo4j (ou pgvector na versão leve). As conversas são convertidas em um grafo de triplas (entidade, relação, entidade). A recuperação combina travessia do grafo com busca vetorial.

Embedding: OpenAI / Cohere, configurável.

Pontos fortes:

• A camada de grafo de conhecimento é realmente poderosa em casos de uso que envolvem acompanhar relações ao longo do tempo (assistentes estilo CRM, agentes de suporte ao cliente).
• Noção de tempo — consegue responder "o que o usuário disse sobre X no mês passado e o que disse esta semana".
• Núcleo open source com uma opção Cloud gerenciada e bem-acabada.

Pontos fracos:

• A camada de grafo acrescenta complexidade de verdade. Para memória de desenvolvimento pura ("lembre que combinamos usar o TanStack Query"), é exagero.
• O self-hosted exige rodar o Neo4j ou saber lidar com os casos-limite do pgvector.
• O suporte a MCP é via wrapper.
• Pensado primeiro para a nuvem — o modo local existe, mas não é o caminho feliz.

Quando escolher: seu agente de IA precisa raciocinar sobre relações entre entidades ao longo do tempo. Casos de uso de CRM, suporte e copiloto de vendas.

Comparativo de latência

É aqui que a divisão entre local e nuvem mais pesa. Rodei 100 consultas de recuperação em cada servidor, com um corpus de 10k itens, no mesmo MacBook M1 (16GB de RAM, internet banda larga).

Três conclusões:

1. SQLite + embeddings locais é 5-10x mais rápido que a segunda opção mais rápida.
2. As APIs em nuvem ficam todas na faixa de 200-500ms. A rede é o gargalo.
3. As versões self-hosted de produtos pensados para a nuvem ainda são mais lentas que uma solução nativa em SQLite, por causa do overhead de IPC + serviços.

Em sessões interativas de código, a diferença de latência é a diferença entre "a memória parece invisível" e "a memória parece estar carregando".

Licença + questões comerciais

Os quatro são Apache 2.0 no núcleo. As diferenças:

• SynaBun — Apache 2.0 de ponta a ponta. Sem fork comercial.
• Mem0 — Apache 2.0 + um serviço gerenciado na nuvem. A nuvem é paga.
• Letta — Apache 2.0 + Letta Cloud (comercial).
• Zep — edição da comunidade em Apache 2.0 + Zep Cloud (comercial). A edição da comunidade tem menos recursos que a Cloud.

Nada na lista traz risco de rug pull. Os quatro têm histórico e mantenedores ativos. Mas, pensando no longo prazo, "totalmente OSS, sem fork comercial" pesa para alguns times.

E o OpenMemory?

O OpenMemory é uma variante local-first compatível com o Mem0. Escopo menor (5 ferramentas MCP, memória pura). Se você gosta do Mem0, mas quer rodar sem a nuvem e sem o Qdrant, o OpenMemory é a escolha certa. Ele roda em Chroma + SQLite.

Não incluí o OpenMemory como opção principal porque, em termos de arquitetura, ele é "o Mem0 sem as partes de nuvem": mesmo modelo de memória, só que mais enxuto.

Como escolher pelo caso de uso

Dev solo que usa o Claude Code todo dia: SynaBun. Ganha em latência, os extras (navegador, loops, hooks) vêm de graça e não precisa de conta na nuvem.

Time criando um assistente de IA voltado para o cliente: Letta. O framework de agentes poupa o trabalho de integração, e os blocos de memória estruturados já foram testados na prática.

Time de produto que integra com vários frameworks de LLM (LangGraph, LlamaIndex, AutoGen): Mem0. Ninguém cobre tantas integrações.

Agente de CRM ou suporte que precisa raciocinar sobre entidades ao longo do tempo: Zep. O grafo de conhecimento é o diferencial exclusivo.

Memória local leve e compatível com o Mem0: OpenMemory.

O que nenhum deles faz bem

A categoria tem lacunas. Nenhum deles resolve:

• Memória entre desenvolvedores. Compartilhar um repositório de memórias com o time sem ter que reimplementar o controle de acesso por conta própria.
• Coleta de lixo de memórias. As memórias antigas se acumulam. Nenhum dos quatro tem uma estratégia sólida além de "defina TTLs" ou "deixe o usuário apagar".
• Busca de memórias em documentos + código. A maioria é ajustada para memórias em estilo de chat. Buscar em um corpus de código + memória de chat em uma única consulta ainda é precário.
• Explicação da recuperação. "Por que esta memória ficou bem ranqueada?" — nenhum deles mostra isso de um jeito que ajude você a ajustar a recuperação.

Se algum desses pontos importa no seu caso de uso, você vai acabar escrevendo código sob medida, seja qual for o servidor escolhido.

Para fechar

A categoria de "memória de IA" vai se fragmentar muito no próximo ano. Os produtos cloud-first vão ficar mais polidos. Os produtos local-first vão ficar mais rápidos e mais capazes. E muitos times vão acabar rodando os dois: local para a memória de desenvolvimento, nuvem para a memória de produção.

Para o trabalho de desenvolvimento, especificamente, o argumento a favor do local é esmagador: menos latência, menos custo, privacidade total. O SynaBun é a minha resposta para esse caso. Os outros três são boas respostas para perguntas diferentes.

Leia também:

• all-MiniLM-L6-v2 para memória vetorial local em servidores MCP
• Memória de IA self-hosted: por que o local vence a nuvem
• SynaBun vs Mem0 (página de comparação completa)
• SynaBun vs Letta (página de comparação completa)