Comparaison de huit bases de données vectorielles gratuites destinées aux agents d’intelligence artificielle : limites, compatibilité et compromis.

Huit bases de données vectorielles reviennent sans cesse lorsque l’on développe des agents avec un budget limité : VectorAI DB Community Edition, Qdrant, Weaviate, Milvus, ChromaDB, LanceDB, pgvector et Pinecone. Chacune d’elles est gratuite au départ. Cela diffère de la gratuité à grande échelle, et c’est encore différent du fait de pouvoir les déployer où que l’agent doive fonctionner.

Les agents s’appuient davantage sur un stockage vectoriel que n’importe quel pipeline RAG. Leur mémoire est écrite et lue à plusieurs reprises au cours de nombreuses sessions. Il est donc nécessaire de savoir si cette mémoire survit à un redémarrage, comment se comportent les temps de réponse lorsque les appels se chevauchent, et si le moteur peut fonctionner à côté de l’agent, même sur un appareil présentant une connexion instable ou absente.

Un plan gratuit ne peut pas couvrir tout cela. Pour évaluer comment la latence se comporte sous une charge concurrente réelle, il faut généralement un plan payant suffisamment puissant pour générer cette charge. Néanmoins, les plans gratuits révèlent où chaque fournisseur fixe ses limites, et certaines de ces limites éliminent déjà une option avant même que du code ne soit écrit. Un service supprime un cluster inactif après 14 jours. Un autre ne propose pas de version auto-hébergée, ce qui l’élimine si les données ne peuvent pas quitter votre infrastructure. Chaque entrée ci-dessous indique clairement ses limites, afin que vous puissiez associer une base de données à votre déploiement et savoir ce que vous renoncerez. Les limites, les plafonds et les prix changent fréquemment, il est donc nécessaire de vérifier les chiffres actuels sur la page de tarification de chaque fournisseur avant de vous engager.

Critères

Huit bases de données ont été comparées selon cinq critères importants pour les agents en particulier.

• Niveau gratuit partiel. Possibilité d’hébergement complet sans limite de vecteurs, un plan gratuit géré avec une limite de stockage ou de vecteurs, ou une bibliothèque plutôt qu’une base de données.
• Modèle de mémoire adapté. Le design de la mémoire des agents est facilité par la base de données.
• Latence sous charge. Comportement du système lorsque plusieurs appels d’agents arrivent en même temps.
• Viabilité en local. Possibilité de faire fonctionner le système entièrement sur ses propres machines sans dépendance au cloud.
• Ce qui pose problème après le niveau gratuit. Le point où quelque chose échoue ou commence à coûter de l’argent.

La plupart des comparaisons publiées visent les charges de travail RAG ou de recommandation, où la base de données répond à des requêtes sans état et est reconstruite à partir d’un ensemble fixe de documents. Les agents se distinguent par le fait qu’ils accumulent de la mémoire au fil des sessions. Le stockage doit conserver l’état et pas seulement répondre aux requêtes, ce qui modifie les compromis acceptables.

Les huit, un par un

1. VectorAI DB Community Edition

VectorAI DB est une base de données vectorielle que vous gérez vous-même, conçue pour fonctionner de manière identique sur un ordinateur portable de développeur et dans un environnement de production déconnecté.

Édition gratuite. L’Édition Communautaire est auto-hébergée et a une limite de 5 000 vecteurs, qui constitue ici la plus faible limite stricte. Un essai gratuit de 30 jours augmenterait apparemment ce plafond à un million de vecteurs. Elle est fournie sous forme d’un seul conteneur Docker sans dépendances externes telles que Kubernetes, etcd ou de systèmes de stockage d’objets. Son créateur a publié des résultats de benchmarks indiquant environ 745 requêtes par seconde avec 10 millions de vecteurs à 768 dimensions sur une machine de 64 GB, ce qui représente une avance de 22 fois par rapport à Milvus et Qdrant Local sur le même matériel. Considérez cela comme une affirmation du fournisseur : elle décrit le moteur payant gérant 10 millions de vecteurs, et non l’édition gratuite limitée à 5 000 vecteurs.

Adéquat pour les agents lorsque l’agent doit se trouver là où se trouvent les données et non là où se situe un centre de données du fournisseur de cloud : sites isolés, règles strictes de résidence des données, matériel de périphérie tel que NVIDIA Jetson et Raspberry Pi, ou tout endroit où l’égress vers le cloud constitue en soi un problème. Le fournisseur propose des configurations prêtes pour le respect des réglementations pour les applications que vous développez, ce qui n’est pas identique à une certification fournie avec l’édition gratuite.

Modèle de mémoire. Mémoire pour les agents de périphérie et hors ligne, ainsi que mémoire durable en général. Les données sont enregistrées sur disque et récupérées après redémarrage, et le fait d’utiliser un seul conteneur pour l’exécution est ce qui rend l’utilisation hors ligne et isolée pratique lorsque Kubernetes n’est pas disponible.

Inconvénient. Vous devez l’héberger vous-même, point final. Il n’existe pas de plan cloud géré gratuit, contrairement à Pinecone ou Qdrant Cloud ; par conséquent, une équipe qui ne souhaite pas que quiconque gère des serveurs devrait choisir une autre solution.

# VectorAI DB -- basic similarity search.

from actian_vectorai import VectorAIClient, VectorParams, Distance

with VectorAIClient("localhost:6574") as client:
    client.collections.create(
        "agent_memory",
        vectors_config=VectorParams(size=768, distance=Distance.Cosine),
    )

    client.points.upsert(
        "agent_memory",
        points=[{"id": 1, "vector": [0.1] * 768, "payload": {"text": "example memory"}}],
    )

    results = client.points.search(
        "agent_memory",
        query_vector=[0.1] * 768,
        limit=5,
    )

2. Qdrant

Qdrant est une base de données vectorielle open source écrite en Rust. Vous pouvez l’héberger vous-même sans limites de vecteurs ou la faire fonctionner sur Qdrant Cloud.

Niveau gratuit. En l’exécutant sur votre propre matériel, Qdrant ne coûte rien et n’a pas de plafond (licence Apache 2.0). Sur Qdrant Cloud, le forfait gratuit offre un nœud unique permanent avec une demi-vCPU, 1 Go de mémoire et 4 Go d’espace de stockage, ce qui est suffisant pour environ un million de vecteurs de 768 dimensions.

Adéquat pour les agents lorsque vous avez besoin d’une recherche rapide et filtrée en production et que vous souhaitez des bibliothèques clients pour Python, TypeScript, Rust, Go, Java et .NET.

Modèle de mémoire. Mémoire persistante des agents. Le filtrage du chargement utile combiné à la recherche vectorielle permet aux agents de stocker des mémoires avec des métadonnées telles que l’utilisateur, la session et l’heure, puis de récupérer un sous-ensemble filtré au moment de la requête.

Inconvénient. Le plan cloud gratuit fonctionne, mais il est limité à 1 Go de RAM. L’hébergement propre permet de lever cette limite, mais ajoute la tâche opérationnelle de gérer et de surveiller son propre cluster. La latence des requêtes varie également en fonction de la taille des ensembles de données et de la complexité des filtres, il convient donc de les tester avec la charge de travail réelle de l’agent.

# Qdrant -- basic similarity search.
from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance, PointStruct

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="agent_memory",
    vectors_config=VectorParams(size=768, distance=Distance.COSINE),
)

client.upsert(
    collection_name="agent_memory",
    points=[PointStruct(id=1, vector=[0.1] * 768, payload={"text": "example memory"})],
)

results = client.query_points(
    collection_name="agent_memory",
    query=[0.1] * 768,
    limit=5,
)

Le stockage en mémoire des agents hébergés localement sur Qdrant est une solution éprouvée aujourd’hui. Pour les sites isolés du réseau, le problème réside dans le fait qu’il vous faut encore gérer toute l’infrastructure vous-même.

3. Weaviate

Weaviate est une base de données vectorielle open source dans laquelle la recherche hybride est intégrée à chaque requête, en combinant des vecteurs densifs avec une recherche par mots-clés BM25.

Niveau gratuit. Weaviate hébergé localement est gratuit et illimité sous une licence BSD-3. Son offre cloud propose actuellement un essai de 14 jours en environnement sandbox, suivi de forfaits payants ; consultez donc la page des tarifs pour connaître les conditions actuelles.

Adéquat pour les agents lorsque une requête doit combiner la recherche par mots-clés avec la similarité sémantique. Un exemple est un agent qui doit retrouver une mémoire correspondant à la fois à un nom d’entité exact et à un concept flou. Weaviate permet ces workflows hybrides via des API REST et GraphQL.

Modèle de mémoire. Mémoire de récupération hybride. Le fait d’associer BM25 aux vecteurs est la raison principale de choisir Weaviate plutôt qu’un moteur vectoriel pur pour la récupération, surtout lorsque la mémoire dépend à la fois d’un concept et d’un terme exact.

Inconvénient. Pour une utilisation hébergée, l’offre gratuite expire : il s’agit d’une période d’essai courte et non d’un abonnement permanent. L’héberger soi-même permet de contourner ce problème, bien que le coût de la mémoire augmente avec la taille des données, car le graphe HNSW est entièrement conservé en RAM.

# Weaviate -- basic similarity search.
import weaviate
from weaviate.classes.config import Configure
from weaviate.classes.query import MetadataQuery

client = weaviate.connect_to_local()

memories = client.collections.create(
    name="AgentMemory",
    vector_config=Configure.Vectors.self_provided(),
)

memories.data.insert(
    properties={"text": "example memory"},
    vector=[0.1] * 768,
)

response = memories.query.near_vector(
    near_vector=[0.1] * 768,
    limit=5,
    return_metadata=MetadataQuery(distance=True),
)

client.close()

Un agent qui doit fonctionner sur du matériel limité plutôt que dans un cluster cloud toujours connecté aura du mal à gérer un index entièrement stocké en RAM.

4. Milvus

Milvus est un moteur distribué open source conçu pour gérer des collections comptant des milliards de vecteurs.

Niveau gratuit. Vous pouvez le télécharger et l’exécuter vous-même sans limite de vecteurs (licence Apache 2.0). Deux modes plus légers existent : Milvus Lite pour un usage local et Standalone pour un seul nœud. Les clusters de production hautement disponibles nécessitent plutôt une architecture distribuée, impliquant Kubernetes, etcd ainsi qu’un stockage d’objets comme MinIO. L’indexation accélérée par GPU est également prise en charge pour des ensembles de données très volumineux.

Il convient aux agents lorsque la base de connaissances contient des centaines de millions de vecteurs ou plus, et que vous souhaitez disposer de onze types d’index ou plus afin d’ajuster le taux de rappel et la vitesse en fonction de chaque collection.

Modèle de mémoire. Mémoire durable à très grande échelle. Il s’avère utile lorsque le volume de données ralentit le stockage en mémoire, mais il n’est pas adapté lorsque la pression provient de nombreuses sessions ou d’un déploiement en périphérie.

Inconvénient. Les coûts d’exploitation sont élevés. Le mode distribué n’est pas adapté aux projets secondaires, l’échelle multi-nœuds introduit une complexité réelle, et il ne convient pas aux environnements en périphérie ou aux matériels limités.

# Milvus -- basic similarity search.
from pymilvus import MilvusClient

client = MilvusClient(uri="http://localhost:19530", token="root:Milvus")

client.create_collection(collection_name="agent_memory", dimension=768)

client.insert(
    collection_name="agent_memory",
    data={"id": 1, "vector": [0.1] * 768, "text": "example memory"},
)

results = client.search(
    collection_name="agent_memory",
    data=[[0.1] * 768],
    limit=5,
)

Lorsque vous souhaitez une solution plus légère, évaluez soigneusement l’installation basée sur Kubernetes avant de vous y engager pour la recherche vectorielle.

5. ChromaDB

ChromaDB est un stockage vectoriel open source que vous intégrez dans votre propre processus, avec presque aucune configuration requise.

Niveau gratuit. Il est gratuit sans limite de vecteurs, que ce soit intégré dans un processus Python ou exécuté en tant que conteneur Docker indépendant. Selon les informations fournies, le projet ne propose aucun service cloud géré, bien qu’une offre hébergée puisse exister aujourd’hui ; vérifiez donc le site du projet.

Adéquat pour les agents lorsque l’objectif est de réaliser rapidement des expériences sur une couche mémoire, en testant les tailles de blocs, les paramètres de récupération et les prompts avant même que toute infrastructure ne soit mise en place.

Modèle de mémoire. Mémoire de travail. Adaptée à une mémoire à courte durée ou en phase de développement au sein d’un seul processus d’agent, mais moins efficace comme stockage à long terme utilisé simultanément par de nombreuses instances d’agents.

Inconvénient. Son efficacité n’a pas été prouvée à grande échelle en production. La suppression d’éléments ne réduit pas l’index, car les suppressions dans le graphe sont coûteuses et la structure HNSW ne cesse de croître ; la fragmentation persiste jusqu’à ce que l’index soit compacté ou reconstruit. Un agent qui ajoute et supprime constamment des mémoires doit alors s’occuper de ce nettoyage, en plus des limites imposées par un seul nœud et des opérations de récupération manuelle.

# ChromaDB -- basic similarity search.
import chromadb

client = chromadb.PersistentClient(path="./agent_memory")
collection = client.get_or_create_collection(name="agent_memory")

collection.add(
    ids=["1"],
    embeddings=[[0.1] * 768],
    documents=["example memory"],
)

results = collection.query(
    query_embeddings=[[0.1] * 768],
    n_results=5,
)

Lorsque plusieurs instances d’agents doivent partager un même stockage mémoire, c’est le modèle intégré qui s’épuise en premier. Une solution courante consiste à utiliser un serveur indépendant auquel se connectent plusieurs processus, et non quelque chose qui fonctionne à l’intérieur d’un seul processus Python.

6. LanceDB

LanceDB est open source et intégré : il fonctionne sur des fichiers stockés dans un système de stockage d’objets et n’a absolument pas besoin de processus serveur.

Niveau gratuit. LanceDB auto-hébergé ou intégré est gratuit, sans limite de vecteurs, sous licence Apache 2.0. Le LanceDB Cloud géré sans serveur était en bêta privée au moment où ce texte a été écrit et nécessitait une application, donc l’auto-hébergement reste la seule solution fiable.

Adapté aux agents lorsque ceux-ci fonctionnent en périphérie ou au sein d’un flux de travail de science des données où un saut réseau vers une base de données distincte est inacceptable, et que vous souhaitez que le stockage soit situé sur le même système de fichiers que le reste du pipeline.

Modèle de mémoire. Mémoire en périphérie et déconnectée. La conception intégrée sans serveur correspond parfaitement à un agent qui ne peut pas disposer d’une connexion stable avec un processus de base de données.

Inconvénient. Le modèle intégré qui en fait la force en périphérie est également ce qui le limite en situation de concurrence. Les systèmes multi-agents comportent souvent plusieurs processus qui écrivent simultanément dans une même table, ce qui représente la charge de travail que les bases de données intégrées gèrent le plus mal. Testez cette configuration avant de valider les changements.

# LanceDB -- basic similarity search.
import lancedb

db = lancedb.connect("./agent_memory")

table = db.create_table(
    "agent_memory",
    data=[{"id": 1, "vector": [0.1] * 768, "text": "example memory"}],
)

results = table.search([0.1] * 768).limit(5).to_list()

7. pgvector

pgvector est une extension pour PostgreSQL qui permet à une base de données que vous utilisez déjà d’effectuer des recherches par similarité vectorielle, de sorte que Postgres reste inchangé sans qu’aucun nouveau système ne soit ajouté.

Niveau gratuit. Cette extension est gratuite et open source. Toute personne qui paie déjà pour Postgres l’obtient gratuitement. Ceux qui ne disposent pas de Postgres doivent adopter une base de données relationnelle complète rien que pour effectuer des recherches vectorielles.

Adéquat pour les agents lorsque l’application fonctionne déjà sur Postgres et qu’un second espace de stockage dédié à la mémoire serait inutile.

Modèle de mémoire. La mémoire persistante est conservée à l’intérieur de la base de données principale. Son avantage par rapport à un moteur dédié réside dans la cohérence transactionnelle, puisque les écritures en mémoire sont confirmées en même temps que les lignes relationnelles de l’application.

Inconvénient. Les bases de données vectorielles conçues spécifiquement le surpassent pour les requêtes filtrées volumineuses, et il n’est pas réaliste de l’utiliser dans des environnements isolés ou en périphérie à moins d’être prêt à y exécuter également une instance complète de Postgres.

# pgvector -- basic similarity search.
import psycopg
from pgvector.psycopg import register_vector

conn = psycopg.connect("dbname=agent_memory")
register_vector(conn)

conn.execute("CREATE EXTENSION IF NOT EXISTS vector")
conn.execute(
    "CREATE TABLE IF NOT EXISTS memories (id bigserial PRIMARY KEY, "
    "text text, embedding vector(768))"
)
conn.execute(
    "INSERT INTO memories (text, embedding) VALUES (%s, %s)",
    ("example memory", [0.1] * 768),
)

results = conn.execute(
    "SELECT text FROM memories ORDER BY embedding <-> %s LIMIT 5",
    ([0.1] * 768,),
).fetchall()

Si votre charge de travail nécessite des performances que pgvector ne peut pas atteindre, vous devrez abandonner complètement le modèle Postgres, et c’est le compromis à prendre en compte.

8. Pinecone

Pinecone fonctionne en tant que service géré sans serveur, et vous ne pouvez pas l’héberger vous-même.

Niveau gratuit. Le plan Starter offre 2 Go d’espace de stockage pour les index, un maximum de cinq indices, deux millions d’unités d’écriture et un million d’unités de lecture par mois, tout cela dans une seule région AWS (us-east-1) et pour un seul projet. Aucune limite de vecteurs n’est indiquée, ce qui signifie que c’est le stockage qui sera le premier à être atteint.

Adéquat pour les agents lorsque vous ne souhaitez pas que quoi que ce soit fonctionne pendant la phase de prototypage et que vous êtes d’accord pour que la mémoire de l’agent soit entièrement hébergée sur l’infrastructure d’un tiers.

Modèle de mémoire. La mémoire est épuisée lors de la création de prototypes. Le plan gratuit est conçu pour des essais et de petits projets, et il ne convient pas au stockage à long terme qui s’accroît avec les agents en environnement de production.

Inconvénient. La limite de stockage n’est pas le principal problème pour les agents ; c’est plutôt l’absence de toute option d’hébergement auto-géré. Si les données doivent rester au sein de votre infrastructure, Pinecone n’est pas une solution, quel que soit l’ampleur du plan gratuit.

# Pinecone -- basic similarity search.
from pinecone import Pinecone, ServerlessSpec
import os

pc = Pinecone(api_key=os.environ["PINECONE_API_KEY"])

pc.create_index(
    name="agent-memory",
    dimension=768,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1"),
)

while not pc.describe_index("agent-memory").status["ready"]:
    pass

index = pc.Index("agent-memory")
index.upsert(vectors=[("1", [0.1] * 768, {"text": "example memory"})])

results = index.query(vector=[0.1] * 768, top_k=5)

Une base de données exclusivement cloud n’est tout simplement pas une option pour les déploiements dont les contraintes excluent complètement les services cloud.

Comment décider

Décidez dans cet ordre : où elle sera déployée, ce que vous exécutez déjà, et à quelle taille elle atteindra.

Le lieu de déploiement vient en premier, car seul ce facteur peut annuler complètement un choix. Une base de données qui n’existe que dans le cloud ne peut pas être placée sur un site isolé, et lorsque la réglementation exige que les données restent en place, aucun forfait gratuit ne change cette réponse. Une limite de stockage n’est qu’un montant que vous payez pour pouvoir l’augmenter ultérieurement.

Deux facteurs échappent à cette séquence logique. Si Postgres est déjà intégré à votre stack, pgvector vous épargne la nécessité d’un deuxième database quel que soit l’endroit où vous le déployez. Si vous visiez une échelle de milliards de vecteurs, Milvus est conçu spécifiquement pour cela dès le départ. Et si vous êtes seulement en phase de prototypage, commencez par ChromaDB localement avant de passer à un service hébergé lorsque vous en avez réellement besoin.

Pour les déploiements sur site, isolés ou en périphérie, la liste réaliste se limite aux options auto-hébergées, à savoir VectorAI DB, Qdrant, Milvus, LanceDB et pgvector ; le choix entre elles dépend de l’échelle requise, des besoins en concurrence et du volume de travail opérationnel que votre équipe peut gérer.