Servidores de memoria MCP: SynaBun vs mem0 vs Letta vs Zep

Ya hay media docena de servidores de memoria de IA serios en circulación, y las páginas de marketing no te ayudan a elegir uno. Cada proyecto destaca lo que hace bien y se salta lo que no.

Este post es la versión honesta. Yo construí uno de ellos (SynaBun), así que tengo un sesgo, y lo voy a señalar cada vez que aparezca. Si algo de lo que digo aquí está mal, escríbeme por Discord y lo corrijo.

Los cuatro servidores

Comparo cuatro proyectos que comparten la misma tarea central (darle a un agente de programación con IA memoria persistente entre sesiones), pero que toman decisiones de arquitectura radicalmente distintas.

• SynaBun — local-first, nativo de MCP, 157 herramientas (memoria + asistente + navegador + redes sociales + whiteboard + loops), Apache 2.0
• Mem0 — orientado a la nube con opción self-hosted, compatible con MCP, 6 herramientas, Apache 2.0
• Letta (antes MemGPT) — orientado a la nube, framework de agentes con bloques de memoria estructurados, Apache 2.0
• Zep — orientado a la nube, capa de grafo de conocimiento, núcleo Apache 2.0 + Cloud comercial

También existen OpenMemory (una variante local-first compatible con Mem0) y Memory Keeper, pero se solapan mucho con los cuatro anteriores.

Matriz de decisión rápida

El resto de este post es la versión larga.

Matriz de funciones

SynaBun

Propuesta: el servidor MCP que lo trae todo. La memoria es una de 157 herramientas, no la única.

Arquitectura: servidor MCP en Node + SQLite (búsqueda por palabras clave con FTS5 y vectores guardados como BLOBs) + embeddings locales. Desde la 2.0.0, la recuperación es híbrida por defecto. Suma una interfaz 3D en React ("Neural Interface") para explorar la memoria, una API REST con Express, hooks de Claude Code y un Schedules Studio para loops controlados por cron. Las herramientas de navegador son un wrapper de Playwright.

Embedding: all-MiniLM-L6-v2 (local, 22MB, 384 dimensiones). Aquí explico las razones en detalle.

Puntos fuertes:

• Con una sola instalación tienes memoria, un asistente que conoce tu memoria y reparte el trabajo entre agentes, navegador, extracción de redes sociales, loops autónomos, bots de Discord, generación de imágenes y video con Leonardo.ai y 30 herramientas de Google Search Console (ninguna requiere clave de API).
• Totalmente local-first. No necesitas una cuenta en la nube para usar ninguna función.
• Compatibilidad de primer nivel con Claude Code, Codex, OpenCode y Gemini.
• El modelo de memoria por categorías (categorías padre/hija, etiquetas de proyecto, puntuación de importancia) encaja de forma natural con la manera en que los desarrolladores organizan de verdad su conocimiento.

Puntos débiles:

• Más funciones implican más cosas que aprender. Si solo quieres memoria, es demasiado.
• Las herramientas de navegador y redes sociales requieren una instancia de Chrome con interfaz gráfica, lo que complica la configuración en servidores headless.
• No hay opción gestionada en la nube. Lo ejecutas tú.

Aviso de sesgo: esto lo construí yo. Todos los demás servidores de este post son opciones que evalué antes de decidirme a escribir el mío.

Cuándo elegirlo: trabajas por tu cuenta, quieres un único servidor MCP que lo haga todo y no te molesta alojarlo tú mismo.

Mem0

Propuesta: el líder de la categoría de memoria de IA. Es a la vez un SaaS alojado y una biblioteca open source.

Arquitectura: biblioteca de Python + API REST + nube opcional. Guarda hechos (extraídos de las conversaciones) en Qdrant y metadatos estructurados en Postgres. La "capa inteligente" intenta deduplicar y actualizar las memorias en lugar de limitarse a añadirlas.

Embedding: text-embedding-3-small de OpenAI por defecto. Se puede cambiar desde la configuración.

Puntos fuertes:

• La mayor base de usuarios de la categoría de memoria de IA. Muchas integraciones y mucha documentación.
• Actualizaciones de memoria «inteligentes»: si un dato nuevo contradice uno anterior, Mem0 intenta fusionarlos.
• La nube alojada no requiere ninguna configuración si no quieres optar por self-hosted.
• Integraciones bien probadas con LangGraph, LlamaIndex y AutoGen.

Puntos débiles:

• La versión self-hosted funciona, pero exige ejecutar Qdrant + Postgres + la API de Mem0. No es tan plug-and-play como SQLite.
• La versión en la nube exige enviar tus datos a los servidores de Mem0. Para algunos equipos eso es motivo de descarte.
• 6 herramientas MCP: una capa de memoria pura, sin herramientas adyacentes.
• La deduplicación «inteligente» de memorias a veces borra contexto que querías conservar. Se puede ajustar, pero lleva trabajo.

Cuándo elegirlo: quieres un servicio de memoria gestionado en la nube, con un panel bien cuidado y una comunidad grande.

Letta (antes MemGPT)

Propuesta: la memoria como un objeto estructurado dentro de un framework de agentes. Está construido en torno al patrón «context manager» del artículo original de MemGPT.

Arquitectura: framework de agentes en Python con tres niveles de memoria: core (siempre en contexto), archival (con búsqueda vectorial) y recall (historial de chat). El propio agente decide cuándo subir o bajar memorias de nivel mediante llamadas a herramientas.

Embedding: OpenAI por defecto, configurable.

Puntos fuertes:

• El modelo de memoria estructurada está realmente bien diseñado. «Core memory» para la personalidad y las preferencias, «archival» para los datos a largo plazo y «recall» para el historial de chat: una separación limpia.
• Stack de Docker que puedes alojar tú mismo. Funciona sin conexión si cambias el proveedor del LLM.
• El artículo original de MemGPT acumula citas académicas desde hace dos años. Tiene un linaje de investigación real.
• SDK de agentes integrado, por si quieres lanzar un producto de IA para tus clientes.

Puntos débiles:

• Más pesado que los demás: Postgres + la API de Letta + el runtime del agente.
• Está pensado para aplicaciones de agentes completas, no para «añadir una capa de memoria a mi sesión de Claude Code».
• La compatibilidad con MCP es mediante un wrapper, no nativa.
• Los bloques de memoria estructurada exigen decidir el esquema desde el principio, y después puede ser difícil migrarlo.

Cuándo elegirlo: estás creando un producto de IA para tus clientes en el que la memoria necesita niveles estructurados, y quieres un framework de agentes que ya los traiga integrados.

Zep

Propuesta: grafo de conocimiento + memoria vectorial. Registra entidades, relaciones y hechos a lo largo del tiempo, no solo texto sin estructura.

Arquitectura: Postgres + Neo4j (o pgvector en la versión ligera). Las conversaciones se convierten en un grafo de tripletas (entidad, relación, entidad). La recuperación combina el recorrido del grafo con la búsqueda vectorial.

Embedding: OpenAI / Cohere, configurable.

Puntos fuertes:

• La capa de grafo de conocimiento es realmente potente cuando hay que seguir relaciones a lo largo del tiempo (asistentes tipo CRM, agentes de atención al cliente).
• Conciencia temporal: puede responder «qué dijo el usuario sobre X el mes pasado y qué dijo esta semana».
• Núcleo open source con una opción Cloud gestionada y bien cuidada.

Puntos débiles:

• La capa de grafo añade una complejidad real. Para memoria de desarrollo pura («recuerda que acordamos usar TanStack Query») es excesiva.
• Alojarlo tú mismo exige ejecutar Neo4j o manejarte bien con los casos límite de pgvector.
• La compatibilidad con MCP es mediante un wrapper.
• Pensado ante todo para la nube: el modo local existe, pero no es el camino principal.

Cuándo elegirlo: tu agente de IA necesita razonar sobre las relaciones entre entidades a lo largo del tiempo. Casos de uso de CRM, soporte y copilotos de ventas.

Comparativa de latencia

Aquí es donde más pesa la diferencia entre local y nube. Ejecuté 100 consultas de recuperación contra cada servidor, con un corpus de 10k elementos, en el mismo MacBook M1 (16GB de RAM, internet de banda ancha).

Tres conclusiones:

1. SQLite + embeddings locales es 5-10x más rápido que la siguiente opción más rápida.
2. Todas las API en la nube se mueven en el rango de 200-500ms. La red es el cuello de botella.
3. Las versiones self-hosted de los productos pensados para la nube siguen siendo más lentas que una solución nativa en SQLite, por la sobrecarga de IPC y de servicios.

En sesiones de programación interactivas, esa diferencia de latencia separa una memoria que «ni se nota» de una memoria que «parece tener pantalla de carga».

Licencia y aspectos comerciales

Los cuatro tienen un núcleo con licencia Apache 2.0. Las diferencias:

• SynaBun: Apache 2.0 de principio a fin. Sin fork comercial.
• Mem0: Apache 2.0 + un servicio gestionado en la nube. La nube es de pago.
• Letta: Apache 2.0 + Letta Cloud (comercial).
• Zep: edición comunitaria con Apache 2.0 + Zep Cloud (comercial). La edición comunitaria tiene menos funciones que Cloud.

Ninguno de la lista conlleva riesgo de rug pull. Los cuatro tienen trayectoria y un mantenimiento activo. Pero, pensando a largo plazo, a algunos equipos les importa que sea «totalmente OSS y sin fork comercial».

¿Y OpenMemory?

OpenMemory es una variante local-first compatible con Mem0. Tiene un alcance menor (5 herramientas MCP, memoria pura). Si te gusta Mem0 pero quieres ejecutarlo sin la nube y sin Qdrant, OpenMemory es la opción adecuada. Funciona sobre Chroma + SQLite.

No lo incluí como opción principal porque, en términos de arquitectura, es "Mem0 sin las partes de nube": el mismo modelo de memoria, con una huella más pequeña.

Cuál elegir según tu caso

Desarrollador independiente que usa Claude Code a diario: SynaBun. Gana en latencia, los extras (navegador, loops, hooks) vienen incluidos y no necesitas cuenta en la nube.

Equipo que construye un asistente de IA de cara al cliente: Letta. El framework de agentes te ahorra el trabajo de conectar todo, y los bloques de memoria estructurada están más que probados en producción.

Equipo de producto que se integra con varios frameworks de LLM (LangGraph, LlamaIndex, AutoGen): Mem0. Nadie iguala su cobertura de integraciones.

CRM o agente de soporte que necesita razonar sobre entidades a lo largo del tiempo: Zep. El grafo de conocimiento es su valor único.

Memoria local ligera y compatible con Mem0: OpenMemory.

Lo que ninguno hace bien

La categoría tiene vacíos. Ninguno resuelve:

• Memoria compartida entre desarrolladores. Compartir un almacén de memorias con todo un equipo sin tener que implementar el control de acceso por tu cuenta.
• Recolección de basura de memorias. Las memorias antiguas se acumulan. Ninguno de los cuatro tiene una estrategia sólida más allá de "configura TTL" o "deja que el usuario las borre".
• Búsqueda de memorias en documentos y código. La mayoría está ajustada para memorias de tipo chat. Buscar en un corpus de código y en la memoria de chat con una sola consulta todavía deja mucho que desear.
• Explicación de la recuperación. "¿Por qué esta memoria quedó tan arriba?": ninguno lo muestra de una forma que te ayude a ajustar la recuperación.

Si algo de esto importa en tu caso, vas a terminar escribiendo código a medida, elijas el servidor que elijas.

Cierre

La categoría de "memoria de IA" se va a fragmentar mucho durante el próximo año. Los productos centrados en la nube van a estar cada vez más pulidos. Los productos local-first van a ser más rápidos y más capaces. Y muchos equipos van a terminar usando ambos: local para la memoria de desarrollo, nube para la memoria de producción.

Para el trabajo de desarrollo en concreto, los argumentos a favor de lo local son abrumadores: menor latencia, menor costo, privacidad total. SynaBun es mi respuesta a ese caso. Los otros tres son buenas respuestas a preguntas distintas.

Lecturas relacionadas:

• Cómo usar all-MiniLM-L6-v2 para memoria vectorial local en servidores MCP
• Memoria de IA self-hosted: por qué lo local le gana a la nube
• SynaBun vs Mem0 (página de comparación completa)
• SynaBun vs Letta (página de comparación completa)