pgvector ou Qdrant — lequel auto-héberger ?

Si vous faites déjà tourner Postgres (ou voulez une seule base pour vos données d'app et vos embeddings), pgvector est le choix le moins coûteux — c'est juste une extension. Si vous avez des millions de vecteurs ou voulez un moteur dédié avec un filtrage rapide, Qdrant mérite le service séparé. Pour la plupart des agents qui débutent, pgvector sur Postgres suffit amplement.

De combien de RAM une base de données vectorielle a-t-elle besoin ?

Plus que vous ne le devineriez, car une bonne recherche veut l'index en mémoire. Règle approximative : quelques centaines de milliers d'embeddings tiennent confortablement dans 2 Go ; dès que vous atteignez quelques millions, prévoyez 4 Go+ et réglez l'index. Commencez à 2 Go, surveillez la mémoire, redimensionnez quand la recherche ralentit.

Pourquoi auto-héberger un stockage vectoriel plutôt qu'un managé ?

Deux raisons pour lesquelles les gens le font vraiment : vos embeddings contiennent souvent vos données privées (notes, docs, contenu client), et un stockage auto-hébergé garde cela sur un serveur que vous contrôlez. Et c'est un coût fixe — un service vectoriel managé facture aux vecteurs et aux requêtes, tandis qu'un VPS est un seul chiffre mensuel sans compteur à la requête.

Une base vectorielle et mon agent peuvent-ils tourner sur le même VPS ?

Oui, pour les charges petites à moyennes — co-localiser l'agent et une instance pgvector/Qdrant sur une machine est simple et réduit la latence à presque zéro. Ne les séparez sur des serveurs distincts que quand l'un commence à affamer l'autre en RAM, ce qui est un beau problème à avoir plus tard, pas une préoccupation du premier jour.

Les embeddings prennent-ils beaucoup de disque ?

Un seul embedding fait quelques kilo-octets, donc un million d'entre eux fait quelques giga-octets plus l'overhead d'index — significatif mais pas énorme. 25–45 Go de disque couvrent un stockage de mémoire substantiel pour la plupart des agents. C'est la RAM, pas le disque, qui est généralement la première limite que vous atteignez.

Héberger une base de données vectorielle pour la mémoire d'un agent IA sur un VPS

Un agent IA sans mémoire est coincé à se réintroduire à chaque conversation. La solution est une base de données vectorielle — elle stocke des embeddings de vos documents, notes ou anciens chats pour que l'agent puisse rappeler les bribes pertinentes à la demande (c'est le « R » de RAG). Vous pouvez louer cela comme service managé, ou vous pouvez le faire tourner vous-même sur un VPS et garder vos données — qui sont souvent vos données privées — sur une machine que vous contrôlez. Voici comment, et ce que cela coûte réellement en RAM.

Deux bonnes options

Vous n'avez besoin de rien d'exotique. Deux voies couvrent presque tout le monde :

pgvector — une extension Postgres. Si vous faites déjà tourner Postgres (ou êtes prêt à le faire), cela ajoute la recherche vectorielle à la base de données que vous avez déjà. Un service, une sauvegarde, du SQL que vous connaissez. Le départ le moins coûteux, de loin.

Qdrant — un moteur vectoriel dédié. Passez-y quand vous avez beaucoup de vecteurs (quelques millions+) ou voulez un filtrage rapide par métadonnées et une API dédiée. C'est un service séparé à faire tourner, mais il est bâti exactement pour ce travail.

Pour la plupart des agents qui trouvent leurs marques, pgvector est la bonne première réponse. Passez à Qdrant quand vous l'avez dépassé, pas avant.

La réalité de la RAM (c'est la partie que les gens sous-estiment)

La recherche vectorielle est rapide parce que l'index vit en mémoire — donc la RAM, pas le disque, est votre vraie contrainte. Un guide approximatif :

Quelques centaines de milliers d'embeddings — confortable dans 2 Go.
Quelques millions — prévoyez 4 Go+ et réglez l'index.
Le disque est la partie facile : un million d'embeddings fait seulement quelques Go, donc 25–45 Go couvrent un stockage sérieux.

Dimensionnez donc pour l'index, pas pour le fichier. (Même logique que le guide de dimensionnement général — la chose lourde n'est pas évidente tant que vous ne mesurez pas.)

Démarrage rapide : pgvector

Sur une machine avec Postgres (Docker est le plus simple — même schéma que l'auto-hébergement de n8n) :

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- match your embedding model's dimensions
);

-- after you have data, build an index for fast search:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

Votre agent insère content + son embedding, puis interroge avec ORDER BY embedding <=> $query_embedding LIMIT 5 pour tirer les mémoires les plus proches. C'est toute la boucle.

Vous préférez Qdrant ? C'est un unique conteneur Docker exposant une API HTTP/gRPC ; vous créez une collection avec votre taille de vecteur et faites un upsert des points. Même idée, moteur dédié.

Peut-elle partager une machine avec l'agent ?

Oui — pour les stockages de mémoire petits à moyens, faites tourner la base vectorielle sur le même VPS que l'agent. C'est plus simple et la latence est quasiment nulle. Ne les séparez sur des serveurs distincts que quand l'un commence à évincer l'autre de la RAM. C'est une décision ultérieure, un beau problème à avoir, pas une décision du premier jour.

Réserves honnêtes

La RAM est le mur, et il est silencieux. La recherche reste rapide jusqu'à ce que l'index ne tienne plus en mémoire, puis elle se dégrade. Surveillez la mémoire et redimensionnez avant que ça morde — n'attendez pas que des requêtes lentes vous le disent.
Les embeddings coûtent des tokens à créer. Chaque document que vous encodez est un appel d'API à un modèle d'embeddings. Le stockage est bon marché à héberger ; générer les vecteurs est le coût récurrent — pertinent pour ce que coûte réellement de faire tourner un agent.
Sauvegardez-la. La mémoire de votre agent est une donnée comme une autre. Si elle compte, faites-en un snapshot.

Dans ce cadre, un stockage vectoriel auto-hébergé est une façon propre de donner à un agent une mémoire durable sans remettre vos données privées à un tiers. Commencez avec pgvector sur une machine de 2 Go, gardez un œil sur la RAM, et grandissez vers Qdrant ou une offre plus grande seulement quand les chiffres vous le disent.