Kuzu queda abandonado y Graphiti se pasa a LadybugDB para memoria de agentes
El backend de grafos embebido que usaba Graphiti está sin mantenimiento. El fork LadybugDB admite un escritor y varios lectores a la vez, algo que un agente que lee mientras ingesta necesita.
Kuzu, la base de datos de grafos embebida que Graphiti usaba para montar memoria de agentes en local, está abandonada aguas arriba y no conviene arrancar trabajo nuevo sobre ella. El relevo lo toma LadybugDB, un fork mantenido que además permite un proceso escritor y varios lectores en solo lectura al mismo tiempo, que es justo lo que necesita un agente que lee mientras se escriben hechos nuevos.
Qué backend embebido aguanta
Graphiti puede correr sin Neo4j ni Docker sobre un fichero local. Las opciones que quedan son tres: Kuzu, deprecado y sin mantenimiento; FalkorDB Lite, que sigue vivo pero solo admite un proceso por fichero; y LadybugDB, el fork mantenido, con un open de lectura-escritura más opens de solo lectura. La diferencia importa más de lo que parece, porque decide si el agente puede seguir consultando mientras entra información nueva.
LadybugDB no tiene driver propio dentro de Graphiti. Al ser una continuación de Kuzu, funciona a través del driver de Kuzu en cuanto el paquete responde al nombre antiguo, con un sys.modules.setdefault que mapea "kuzu" a ladybug. Hay una trampa en ese camino: el driver de Kuzu declara sus índices de texto completo, pero su build_indices_and_constraints no hace nada, así que los índices nunca se crean y cualquier búsqueda híbrida revienta con una excepción Binder. Toca crearlos a mano en el primer open de lectura-escritura.
El escritor no debería ser el agente
Con un fichero embebido el camino de escritura queda a la vista, porque solo un proceso puede tenerlo abierto para escribir. El autor lo convierte en diseño: los lectores abren en solo lectura y el único open de lectura-escritura lo ejecuta una persona. El servidor MCP expone seis herramientas y todas son de lectura. Cuando el agente aprende algo, deja una propuesta fuera del fichero del grafo; nada llega al grafo hasta que alguien la aprueba y lanza el drain. La razón es concreta: un modelo de 7B convirtiendo una nota de reunión en tres entidades seguras de sí mismas y falsas. Una respuesta mala se reintenta; un recuerdo malo vuelve una y otra vez. Antes de la 0.3.0 el servidor retenía el lock de escritura y dejaba fuera a cualquier otro comando; abrir los lectores en solo lectura lo resolvió, y el servidor recoge lo que escribió el drain sin reiniciarse.
Los números que da, medidos en un Apple M5 con 32 GiB sobre el fixture sintético que viene con el proyecto y sin contar descargas de modelos ni dependencias: 1,3 segundos para preparar la base, 0,5 para el diagnóstico, 34,4 para la ingesta con extracción local, 1,3 por consulta y 44,7 para aprobar y aplicar una actualización. La recuperación es rápida; la extracción es la que hay que batchear o dejar de noche.
Un aviso que se lleva por delante bases enteras sin dar error: los vectores de un embedder no son comparables con los de otro, ni siquiera con el mismo nombre de modelo. En sus grafos, nomic-embed-text sobre una segunda compilación de Ollama dio 0,80 de coseno frente a vectores guardados donde el original daba 1,00. Nada falla, simplemente todo ordena un poco peor. El proyecto anota qué embedder escribió la base y aborta con código 2 si la ingesta llega con otro. La anchura es el segundo fallo silencioso: nomic-embed-text devuelve 768 dimensiones, no las 1536 que asume un valor por defecto de OpenAI.
El fichero embebido deja de tener sentido en varios escenarios: varios usuarios o inquilinos en el mismo despliegue, porque un fichero es un grafo y no puede imponer frontera entre grupos; agentes que necesiten escribir directamente, que por diseño aquí no pueden; ingesta masiva, donde el modelo local marca el suelo de velocidad; y dependencias de largo plazo sobre el driver de Kuzu, que Graphiti tiene marcado como deprecado y que LadybugDB sigue usando por debajo.
La decisión de fondo no es qué base de datos mola más, sino cuánta concurrencia necesita la memoria del agente y quién tiene permiso para escribir en ella. Si el proyecto crece a multiusuario o a escritura autónoma, toca volver a Neo4j o FalkorDB. El repositorio acepta informes de instalación, incluidos los bloqueos, y el arreglo de los índices de texto completo salió de uno de ellos.
