El patrón dominante en la infraestructura de AI agents es: vector database para recall semántico, key-value store para estado de sesión, base de datos relacional para datos de usuario, object storage para artefactos. Cuatro sistemas, cuatro clientes, cuatro modos de fallo. Esto funciona a escala, pero es overkill para el 90% de los agentes que operan en una sola máquina con un solo usuario.
Lo que los agentes realmente necesitan
Un agente necesita recordar. Específicamente, necesita: almacenar observaciones con metadata estructurada, recuperar observaciones pasadas relevantes por similaridad semántica, obtener records exactos por clave, sobrevivir a crashes sin perder memorias committed, y hacer todo esto sin una dependencia de red. Eso no son cinco bases de datos. Es una base de datos con cinco capacidades.
VantaDB como capa de memoria
VantaDB provee exactamente esta superficie. put() almacena un payload con metadata y un vector opcional. get() recupera por clave exacta. search() corre retrieval híbrido. El WAL con CRC32C garantiza durabilidad. El core embebido en Rust significa que no hay servidor que manejar. Los bindings Python significan que la integración está a un pip install de distancia.
La analogía con SQLite es deliberada. SQLite no reemplazó a PostgreSQL — reemplazó los casos donde PostgreSQL era overkill. VantaDB no reemplaza a Pinecone — reemplaza los casos donde una vector database network-attached tiene la forma equivocada para el problema. Para agentes corriendo localmente, esa es la mayoría de los casos.
Corre los benchmarks en tu propia máquina
Instala con pip install vantadb-py y reproduce los números de batch de docs/operations/BENCHMARKS.md en tu hardware. Dale una estrella al repo y comparte tus resultados en el Discord — después lee How Hybrid Search Actually Works para ver cómo el planner fusiona BM25 y HNSW.