Aloja una base de datos vectorial para la memoria de un agente de IA en un VPS

Un agente de IA sin memoria se queda reintroduciéndose cada conversación. La solución es una base de datos vectorial — almacena embeddings de tus documentos, notas o chats pasados para que el agente pueda recordar las partes relevantes bajo demanda (esa es la «R» de RAG). Puedes alquilarlo como servicio gestionado, o puedes ejecutarlo tú mismo en un VPS y mantener tus datos — que a menudo son tus datos privados — en una máquina que controlas. Aquí está cómo, y lo que cuesta realmente en RAM.

Dos buenas opciones

No necesitas nada exótico. Dos caminos cubren a casi todos:

pgvector — una extensión de Postgres. Si ya ejecutas Postgres (o estás contento de hacerlo), esto añade búsqueda vectorial a la base de datos que ya tienes. Un servicio, una copia de seguridad, SQL que conoces. El comienzo de menor esfuerzo por amplio margen.

Qdrant — un motor vectorial a medida. Recurre a él cuando tengas muchos vectores (millones bajos+) o quieras filtrado rápido de metadatos y una API dedicada. Es un servicio aparte que ejecutar, pero está construido para exactamente este trabajo.

Para la mayoría de los agentes que dan sus primeros pasos, pgvector es la primera respuesta correcta. Pasa a Qdrant cuando lo hayas superado, no antes.

La realidad de la RAM (esta es la parte que la gente subestima)

La búsqueda vectorial es rápida porque el índice vive en memoria — así que la RAM, no el disco, es tu restricción real. Una guía aproximada:

• Unos pocos cientos de miles de embeddings — cómodo en 2 GB.
• Millones bajos — planea 4 GB+ y afina el índice.
• El disco es la parte fácil: un millón de embeddings son solo unos pocos GB, así que 25–45 GB cubren un almacén serio.

Así que dimensiona para el índice, no para el archivo. (La misma lógica que la guía general de dimensionamiento — lo pesado no es obvio hasta que lo mides.)

Inicio rápido: pgvector

En una máquina con Postgres (Docker es lo más fácil — el mismo patrón que autoalojar n8n):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- coincide con las dimensiones de tu modelo de embeddings
);

-- después de tener datos, construye un índice para búsqueda rápida:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

Tu agente inserta content + su embedding, luego consulta con ORDER BY embedding <=> $query_embedding LIMIT 5 para extraer los recuerdos más cercanos. Ese es todo el bucle.

¿Prefieres Qdrant? Es un único contenedor Docker que expone una API HTTP/gRPC; creas una colección con tu tamaño de vector y haces upsert de puntos. La misma idea, motor dedicado.

¿Puede compartir máquina con el agente?

Sí — para almacenes de memoria pequeños a medianos, ejecuta la BD vectorial en el mismo VPS que el agente. Es más simple y la latencia es básicamente cero. Sepáralos en servidores distintos solo cuando uno empiece a expulsar al otro de la RAM. Esa es una decisión posterior, buen-problema-para-tener, no una del primer día.

Salvedades honestas

• La RAM es el muro, y es silencioso. La búsqueda se mantiene rápida hasta que el índice ya no cabe en memoria, luego se degrada. Vigila la memoria y cambia el tamaño antes de que muerda — no esperes a que las consultas lentas te lo digan.
• Los embeddings cuestan tokens de crear. Cada documento que embebes es una llamada de API a un modelo de embeddings. El almacén es barato de alojar; generar los vectores es el coste recurrente — relevante para lo que cuesta realmente ejecutar un agente.
• Haz copia de seguridad. La memoria de tu agente son datos como cualquier otro. Si importa, hazle un snapshot.

Dentro de eso, un almacén vectorial autoalojado es una forma limpia de dar a un agente memoria duradera sin entregar tus datos privados a un tercero. Empieza con pgvector en una máquina de 2 GB, vigila la RAM, y crece a Qdrant o a un plan más grande solo cuando los números te lo digan.