Vergleich von acht kostenlosen Vektordatenbanken für KI-Agenten: Grenzen, Eignung und Kompromisse

Acht Vektordatenbanken tauchen immer wieder auf, wenn Menschen Agenten mit begrenztem Budget entwickeln: VectorAI DB Community Edition, Qdrant, Weaviate, Milvus, ChromaDB, LanceDB, pgvector und Pinecone. Jede davon ist zunächst kostenlos verfügbar. Das unterscheidet sich von einer kostenlosen Lösung in großem Maßstab und wiederum von einer Lösung, die überall dort eingesetzt werden kann, wo der Agent laufen muss.

Agenten sind stärker auf einen Vektorspeicher angewiesen als ein einzelner RAG-Pipeline-Workflow je sein könnte. Ihr Speicher wird in vielen Sitzungen immer wieder geschrieben und gelesen. Daher muss man wissen, ob dieser Speicher auch nach einem Neustart erhalten bleibt, wie sich die Antwortzeiten verhalten, wenn Anfragen übereinanderliegen, und ob der Engine neben dem Agent laufen kann – selbst auf einem Gerät mit instabiler oder fehlender Verbindung.

Ein kostenloses Abo reicht nicht aus, um all das zu bewältigen. Um zu erkennen, wie die Latenz unter echter gleichzeitiger Belastung aussieht, benötigt man in der Regel ein kostenpflichtiges Abo mit ausreichender Kapazität, um diese Belastung zu erzeugen. Dennoch zeigen kostenlose Angebote, wo jeder Anbieter seine Grenzen setzt – einige dieser Grenzen schließen bereits vor dem Schreiben von Code eine Option aus. Ein Service löscht einen inaktiven Cluster nach 14 Tagen. Ein anderer bietet keine selbst gehostete Version an, was ihn ausschließt, wenn Daten nicht Ihre Infrastruktur verlassen dürfen. Jeder Eintrag unten gibt seine Grenzen klar an, sodass Sie eine Datenbank mit Ihrer Implementierung abgleichen und erkennen können, was Sie aufgeben müssten. Grenzen, Obergrenzen und Preise ändern sich häufig, daher sollten Sie die aktuellen Zahlen auf der Preisseite des jeweiligen Anbieters überprüfen, bevor Sie sich entscheiden.

Kriterien

Acht Datenbanken wurden anhand von fünf Punkten verglichen, die insbesondere für Agenten relevant sind.

• Art des kostenlosen Tarifs. Vollständig selbsthostbar ohne Vektorbegrenzung, ein verwalteter kostenloser Plan mit Speicher- oder Vektorlimit oder eine Bibliothek statt einer Datenbank.
• Passendes Speichermuster. Welches Agent-Speicherdesign die Datenbank erleichtert.
• Verzögerung unter Last. Wie sich das System verhält, wenn mehrere Agentenanfragen gleichzeitig eintreffen.
• Eignung für On-Premise-Installationen. Ob es vollständig auf eigenen Maschinen ohne Cloud-Abhängigkeit laufen kann.
• Was nach dem kostenlosen Tarif zum Problem wird. Der Punkt, an dem etwas versagt oder Kosten verursacht.

Die meisten veröffentlichten Vergleiche beziehen sich auf RAG- oder Empfehlungsaufgaben, bei denen die Datenbank stateless-Anfragen beantwortet und aus einer festen Menge an Dokumenten neu aufgebaut wird. Agenten unterscheiden sich dadurch, dass sie über Sessions hinweg Erinnerungen ansammeln. Der Speicher muss den Zustand persistieren und nicht nur Abfragen beantworten, was die akzeptablen Kompromisse verändert.

Die acht, einer nach dem anderen

1. VectorAI DB Community Edition

VectorAI DB ist eine Vektor-Datenbank, die man selbst betreibt und die dafür konzipiert ist, sowohl auf einem Entwickler-Laptop als auch an einem getrennten Produktionsstandort identisch zu funktionieren.

Kostenlose Version. Die Community Edition wird selbst gehostet und ist auf 5.000 Vektoren begrenzt, was die geringste feste Grenze darstellt. Berichten zufolge erhöht eine separate 30-tägige Testversion diese Obergrenze auf eine Million. Sie wird als einzelner Docker-Container ohne externe Abhängigkeiten wie Kubernetes, etcd oder Objektspeicher bereitgestellt. Der Hersteller hat Benchmark-Ergebnisse veröffentlicht, die eine Leistung von etwa 745 Abfragen pro Sekunde bei 10 Millionen 768-dimensionalen Vektoren auf einem 64-GB-Rechner angeben, wobei er dabei einen Vorsprung von 22 Mal gegenüber Milvus und Qdrant Local auf derselben Hardware vorweist. Dies gilt als Angabe des Anbieters: Sie beschreibt den bezahlten Engine bei 10 Millionen Vektoren und nicht die kostenlose Version mit 5.000 Vektoren.

Geeignet für Agenten, wenn der Agent dorthin laufen muss, wo sich die Daten befinden, und nicht dorthin, wo ein Cloud-Anbieter ein Rechenzentrum hat: Standorte mit Air-Gap-Schutz, strenge Vorschriften zur Datenspeicherung, Edge-Hardware wie NVIDIA Jetson und Raspberry Pi oder überall dort, wo der Cloud-Ausgang selbst ein Problem darstellt. Der Anbieter beschreibt konformitätsbereite Konfigurationen für auf ihnen basierende Anwendungen, was nicht dasselbe ist wie eine Zertifizierung, die mit der kostenlosen Edition geliefert wird.

Gedächtnismuster. Speicher für Edge- und Offline-Agenten sowie robuster Speicher im Allgemeinen. Daten werden auf die Festplatte geschrieben und nach einem Neustart wieder geladen, und gerade die Möglichkeit, nur einen Container auszuführen, macht den Einsatz im Offline- oder Air-Gap-Bereich praktikabel, wenn Kubernetes nicht zur Verfügung steht.

Nachteil. Man muss es selbst hosten, Punkt. Es gibt kein kostenloses, verwaltetes Cloud-Plan wie bei Pinecone oder Qdrant Cloud, daher sollte ein Team, das nicht möchte, dass jemand Server betreibt, sich anders entscheiden.

# 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 ist eine Open-Source-Vektordatenbank, die in Rust geschrieben wurde. Sie können sie selbst hosten, ohne auf Vektorlimits zu stoßen, oder sie auf Qdrant Cloud ausführen.

Kostenloser Tier. Wenn Sie sie auf Ihrer eigenen Hardware betreiben, kostet Qdrant nichts und es gibt keine Obergrenzen (Apache 2.0). Auf Qdrant Cloud bietet der kostenfreie Plan einen dauerhaften Einzelknoten mit einer halben vCPU, 1 GB Speicher und 4 GB Speicherkapazität – das reicht in etwa für eine Million Vektoren mit 768 Dimensionen.

Geeignet für Agenten, wenn Sie in der Produktion eine schnelle, gefilterte Suche benötigen und Client-Bibliotheken für Python, TypeScript, Rust, Go, Java und .NET wünschen.

Gedächtnismodell. Persistentes Agenten-Gedächtnis. Die Kombination aus Payload-Filterung und Vektorsuche ermöglicht es Agenten, Erinnerungen mit Metadaten wie Benutzer, Sitzung und Zeitstempel zu speichern und zum Zeitpunkt der Abfrage ein gefiltertes Unterensemble abzurufen.

Nachteil. Der kostenlose Cloud-Plan funktioniert zwar, ist aber auf 1 GB RAM begrenzt. Durch Selbsthosting wird diese Grenze aufgehoben, doch es entstehen zusätzliche Verwaltungsaufgaben durch den Betrieb und die Überwachung des eigenen Clusters. Zudem ändert sich die Abfrageverzögerung je nach Größe des Datensatzes und Komplexität der Filter, weshalb man anhand der tatsächlichen Arbeitslast des Agents testen sollte.

# 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,
)

Die selbst gehostete Agenten-Speicherung in Qdrant ist heute eine bewährte Lösung. Bei völlig isolierten Standorten besteht jedoch die Herausforderung, dass man weiterhin die gesamte Infrastruktur selbst betreuen muss.

3. Weaviate

Weaviate ist eine Open-Source-Vektordatenbank, in der die hybride Suche in jede Abfrage integriert ist – dabei werden dichte Vektoren mit BM25-Schlüsselwortabgleichen kombiniert.

Kostenlose Version. Die selbst gehostete Variante von Weaviate ist unter einer BSD-3-Lizenz kostenlos und unbegrenzt nutzbar. Das Cloud-Angebot bietet derzeit einen 14-tägigen Sandbox-Test, danach sind gebuchte Pläne erforderlich; prüfen Sie daher die Preisseite für aktuelle Konditionen.

Geeignet für Agenten, wenn eine Abfrage sowohl Schlüsselwortabgleiche als auch semantische Ähnlichkeit kombinieren muss. Ein Beispiel ist ein Agent, der sich an eine Erinnerung erinnern soll, die sowohl einen exakten Entitätsnamen als auch ein ungenaues Konzept berücksichtigen muss. Weaviate bietet solche hybriden Arbeitsabläufe über REST- und GraphQL-APIs an.

Gedächtnismuster. Hybrides Abrufgedächtnis. Die Kombination von BM25 mit Vektoren ist der Hauptgrund, warum man bei der Abruffunktion Weaviate statt eines reinen Vektorengins wählt – insbesondere dann, wenn sich das Gedächtnis sowohl auf ein Konzept als auch auf einen exakten Begriff stützt.

Nachteil. Bei gehosteter Nutzung läuft das kostenlose Angebot ab: Es handelt sich um einen kurzen Testzeitraum und nicht um ein dauerhaftes Abo. Die eigene Hosting-Lösung umgeht dieses Problem, allerdings steigen die Kosten für das Gedächtnis mit der Datenmenge an, da das HNSW-Graph vollständig im RAM gespeichert wird.

# 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()

Ein Agent, der auf eingeschränktem Edge-Hardware-Setup statt in einem ständig verbundenen Cloud-Cluster laufen muss, wird feststellen, dass ein Index, der vollständig im RAM gespeichert ist, schwer zu verwalten ist.

4. Milvus

Milvus ist ein Open-Source-, verteilter Engine, der für Datensammlungen konzipiert ist, die in die Milliarden von Vektoren gehen.

Kostenlose Version. Man kann ihn selbst herunterladen und ausführen, ohne Begrenzung der Vektorenanzahl (Apache 2.0). Es existieren zwei leichtere Modi: Milvus Lite für lokale Nutzung und Standalone für einen einzigen Knoten. Hochverfügbare Produktionscluster benötigen hingegen die verteilte Architektur, wofür Kubernetes, etcd sowie ein Objektspeicher wie MinIO verwendet werden. Für sehr große Datensätze wird außerdem GPU-gestützte Indexierung unterstützt.

Geeignet für Agenten, wenn die Wissensbasis Hunderte Millionen oder mehr Vektoren umfasst und man eine Auswahl von elf oder mehr Indextypen haben möchte, um die Abrufrate sowie Geschwindigkeit für jede Datensammlung individuell anzupassen.

Speichermuster. Langlebiger Speicher in sehr großem Maßstab. Er kommt zum Einsatz, wenn das Datenvolumen die Speicherleistung verlangsamt, ist jedoch ungeeignet, wenn der Druck von vielen Sitzungen oder der Edge-Einsatz ausgeht.

Nachteil. Die Betriebskomplexität ist hoch. Der verteilte Betrieb eignet sich nicht für Nebenprojekte, die Skalierung über mehrere Knoten bringt echte Komplexität mit sich, und er ist nicht für Edge-Umgebungen oder eingeschränktes Hardware-Zubehör geeignet.

# 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,
)

Falls Sie etwas Leichteres suchen, sollten Sie die auf Kubernetes basierende Lösung sorgfältig abwägen, bevor Sie sie für die Vektorabfrage einsetzen.

5. ChromaDB

ChromaDB ist ein Open-Source-Vektor-Speicher, den Sie ohne nennenswerte Einrichtung in Ihren eigenen Prozess integrieren können.

Kostenlose Version. Sie ist kostenlos und kennt keine Limits für Vektoren – egal ob sie in einem Python-Prozess integriert oder als eigenständiger Docker-Container ausgeführt wird. Laut den Quellen bietet das Projekt keinen verwalteten Cloud-Dienst an, es könnte jedoch bereits eine gehostete Variante existieren; prüfen Sie daher die Projektseite.

Geeignet für Agenten, wenn das Ziel schnelle Experimente mit einer Speicherschicht ist, um Größen von Datenblöcken, Abrufeinstellungen und Anfragen auszuprobieren, bevor eine Infrastruktur vorhanden ist.

Gedächtnismuster. Arbeitsgedächtnis. Geeignet für kurzlebiges oder entwicklungsmäßig bedingtes Gedächtnis innerhalb eines Agentenprozesses, aber weniger geeignet als langfristiger Speicher, den viele Agenteninstanzen gleichzeitig nutzen.

Nachteil. Es wurde noch nicht in großem Produktionsmaßstab erprobt. Das Entfernen von Elementen verkleinert den Index nicht, da Graph-Deletionen aufwändig sind und die HNSW-Struktur nur wächst; die Fragmentierung bleibt bestehen, bis der Index komprimiert oder neu aufgebaut wird. Ein Agent, der ständig Erinnerungen hinzufügt und löscht, muss diese Aufräumarbeiten selbst übernehmen, außerdem sind die Grenzen eines Knotens sowie eine manuelle Wiederherstellung zu berücksichtigen.

# 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,
)

Wenn mehrere Agent-Instanzen einen gemeinsamen Speicher teilen müssen, ist das eingebettete Modell das Erste, was an Kapazität verliert. Eine eigenständige Server-Instanz, zu der mehrere Prozesse verbunden werden, ist die übliche Lösung – und nicht etwas, das innerhalb eines einzigen Python-Prozesses läuft.

6. LanceDB

LanceDB ist open source und eingebettet: Es arbeitet mit Dateien in Objektspeichern und benötigt überhaupt keinen Serverprozess.

Kostenlose Version. Selbst gehostetes oder eingebettetes LanceDB ist kostenlos, es gibt keine Vektorlimits, und es unterliegt der Lizenz Apache 2.0. Der verwaltete serverlose LanceDB Cloud befand sich in einer privaten Beta-Phase, und zum Zeitpunkt der Erstellung des Textes war eine Anwendung erforderlich – daher ist das Selbsthosting der einzige zuverlässige Weg.

Geeignet für Agenten, wenn diese am Edge oder innerhalb eines Datenwissenschafts-Werkflows laufen, wo ein Netzwerkwechsel zu einer separaten Datenbank inakzeptabel ist und man möchte, dass der Speicher im selben Dateisystem wie der Rest des Pipelines liegt.

Gedächtnismuster. Rand- und getrenntes Gedächtnis. Das eingebettete, serverlose Design passt perfekt zu einem Agenten, der keine stabile Verbindung zu einem Datenbankprozess annehmen kann.

Nachteil. Das eingebettete Modell, das es am Rand leistungsfähig macht, ist zugleich der Faktor, der es bei Konkurrenz einschränkt. Mehr-Agenten-Systeme haben oft mehrere Prozesse, die gleichzeitig in eine Tabelle schreiben – genau diese Arbeitslast wird von einem im Prozess befindlichen Speicher am schlechtesten bewältigt. Prüfen Sie diesen Fall vor dem Einsatz.

# 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 ist eine Erweiterung für PostgreSQL, die einer bereits genutzten Datenbank die Möglichkeit gibt, mithilfe von Vektorähnlichkeit zu suchen – dadurch bleibt Postgres erhalten, ohne dass ein neues System hinzugefügt werden muss.

Kostenlose Version. Die Erweiterung kostet nichts und ist open source. Jeder, der bereits für Postgres bezahlt, erhält sie kostenlos. Wer keinen Postgres besitzt, muss einen ganzen relationellen Datenbank-System einsetzen, nur um Vektoren suchen zu können.

Geeignet für Agenten, wenn die Anwendung bereits auf Postgres läuft und ein zusätzlicher Datenspeicher nur für den Arbeitsspeicher unerwünscht wäre.

Gedächtnismodell. Dauerhaftes Gedächtnis, das innerhalb der Hauptdatenbank gespeichert wird. Im Vergleich zu einem dedizierten Engine bietet es Transaktionskonsistenz, da Schreibvorgänge im Arbeitsspeicher zusammen mit den relationellen Zeilen der Anwendung gesichert werden.

Nachteil. Speziell entwickelte Vektordatenbanken übertrifft es bei großen, gefilterten Abfragen, und es ist nicht realistisch für isolierte oder edge-basierte Umgebungen – es sei denn, man ist bereit, dort ebenfalls eine vollständige Postgres-Instanz zu betreiben.

# 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()

Falls Ihre Arbeitslast eine Leistungsgrenze erfordert, die pgvector nicht erreichen kann, müssen Sie das Postgres-Modell vollständig verlassen – das ist der Kompromiss, den Sie abwägen müssen.

8. Pinecone

Pinecone wird als verwalteter, serverloser Service betrieben, und Sie können ihn nicht selbst hosten.

Kostenloser Tier. Der Starter-Plan bietet 2 GB Speicher für Indizes, maximal fünf Indizes, zwei Millionen Schreibvorgänge und eine Million Lesevorgänge pro Monat – alles in einer einzigen AWS-Region (us-east-1) und für ein Projekt. Es gibt keine offiziell angegebene Vektorbegrenzung, was bedeutet, dass der Speicher zuerst erschöpft wird.

Geeignet für Agenten, wenn Sie während des Prototypierens keine Aktivitäten wünschen und in Ordnung finden, dass das Gedächtnis des Agenten vollständig auf der Infrastruktur eines Dritten liegt.

Gedächtnismuster. Beim Prototypenbau wird das Gedächtnis belegt. Der kostenlose Plan ist für Tests und kleine Projekte gedacht und eignet sich nicht für den wachsenden Langzeitspeicher von Agenten in der Produktion.

Nachteil. Die Speicherkapazität ist für Agenten nicht das Hauptproblem – vielmehr fehlt eine Option zur Selbsthosting. Wenn die Daten in Ihrer eigenen Infrastruktur bleiben müssen, ist Pinecone ungeeignet, egal wie großzügig der kostenlose Plan auch sein mag.

# 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)

Eine rein cloudbasierte Datenbank ist einfach keine Option für Implementierungen, deren Einschränkungen den Einsatz von Cloud-Diensten gänzlich ausschließen.

Wie man sich entscheidet

Entscheiden Sie in dieser Reihenfolge: Wo wird sie eingesetzt, was läuft bereits dort, und wie groß wird sie werden.

Zuerst kommt die Frage nach dem Einsatzort, denn nur dieser Faktor kann eine Entscheidung vollständig verhindern. Eine Datenbank, die ausschließlich in der Cloud existiert, kann nicht auf einem abgeschirmten Standort platziert werden, und wenn Vorschriften erfordern, dass Daten vor Ort bleiben, ändert kein kostenloses Abo daran etwas. Eine Speicherkapazität ist lediglich eine Zahl, für die man später bezahlt, um sie erhöhen zu können.

Zwei Aspekte fallen außerhalb dieser Abfolge. Wenn Postgres bereits in Ihrem Technologiestack vorhanden ist, spart pgvector Ihnen bei jeder Bereitstellung eine zusätzliche Datenbank. Wenn Sie auf einer Skala von Milliarden Vektoren arbeiten möchten, ist Milvus die Lösung, die von Anfang an dafür konzipiert wurde. Und wenn Sie nur prototypen, sollten Sie mit ChromaDB lokal beginnen und erst zu einem gehosteten Endpoint wechseln, wenn Sie wirklich einen benötigen.

Für On-Premises-, air-gapped- oder Edge-Bereitstellungen sind die realistischen Optionen die selbsthostbaren Lösungen, nämlich VectorAI DB, Qdrant, Milvus, LanceDB und pgvector. Die Wahl unter ihnen hängt von der Skalierbarkeit, den Konkurrenzanforderungen sowie davon ab, wie viel Betriebsarbeit Ihr Team bewältigen kann.