pgvector oder Qdrant — was sollte ich selbst hosten?

Wenn du bereits Postgres betreibst (oder eine Datenbank für App-Daten und Embeddings willst), ist pgvector die aufwandsärmste Wahl — es ist nur eine Erweiterung. Wenn du Millionen von Vektoren hast oder eine zweckgebaute Engine mit schnellem Filtern willst, ist Qdrant den separaten Dienst wert. Für die meisten Agenten am Anfang ist pgvector auf Postgres reichlich.

Wie viel RAM braucht eine Vektordatenbank?

Mehr, als du raten würdest, denn gute Suche will den Index im Speicher. Grobe Regel: ein paar hunderttausend Embeddings sitzen bequem in 2 GB; sobald du niedrige Millionen erreichst, plane 4 GB+ und tune den Index. Starte mit 2 GB, beobachte den Speicher, skaliere, wenn die Suche langsamer wird.

Warum einen Vektorspeicher selbst hosten statt eines verwalteten?

Zwei Gründe, warum Leute es tatsächlich tun: deine Embeddings enthalten oft deine privaten Daten (Notizen, Dokumente, Kundeninhalte), und ein selbst gehosteter Speicher hält das auf einem Server, den du kontrollierst. Und es ist Pauschalkosten — ein verwalteter Vektordienst rechnet nach Vektoren und Abfragen ab, während ein VPS eine monatliche Zahl ohne Meter pro Abfrage ist.

Können eine Vektor-DB und mein Agent auf demselben VPS laufen?

Ja, für kleine bis mittlere Workloads — den Agenten und eine pgvector/Qdrant-Instanz auf einer Maschine zu co-lokalisieren, ist einfach und senkt die Latenz auf nahezu null. Trenne sie nur auf separate Server, wenn einer beginnt, dem anderen den RAM zu entziehen, was später ein schönes Problem ist, keine Sorge von Tag eins.

Brauchen Embeddings viel Platz?

Ein einzelnes Embedding sind ein paar Kilobyte, eine Million davon sind also ein paar Gigabyte plus Index-Overhead — bedeutsam, aber nicht riesig. 25–45 GB Platz decken einen beträchtlichen Gedächtnisspeicher für die meisten Agenten. RAM, nicht Platz, ist meist das erste Limit, auf das du triffst.

Eine Vektordatenbank für KI-Agenten-Gedächtnis auf einem VPS hosten

Ein KI-Agent ohne Gedächtnis steckt fest, sich in jeder Unterhaltung neu vorzustellen. Die Lösung ist eine Vektordatenbank — sie speichert Embeddings deiner Dokumente, Notizen oder vergangenen Chats, sodass der Agent die relevanten Teile bei Bedarf abrufen kann (das ist das „R“ in RAG). Du kannst das als verwalteten Dienst mieten oder es selbst auf einem VPS betreiben und deine Daten — die oft deine privaten Daten sind — auf einer Maschine halten, die du kontrollierst. Hier steht wie, und was es tatsächlich an RAM kostet.

Zwei gute Optionen

Du brauchst nichts Exotisches. Zwei Wege decken fast jeden ab:

pgvector — eine Postgres-Erweiterung. Wenn du bereits Postgres betreibst (oder gern würdest), fügt das die Vektorsuche zur Datenbank hinzu, die du schon hast. Ein Dienst, ein Backup, SQL, das du kennst. Der aufwandsärmste Start mit großem Abstand.

Qdrant — eine zweckgebaute Vektor-Engine. Greif dazu, wenn du viele Vektoren hast (niedrige Millionen+) oder schnelles Metadaten-Filtern und eine dedizierte API willst. Es ist ein separater Dienst, aber er ist genau für diese Aufgabe gebaut.

Für die meisten Agenten, die ihre Beine finden, ist pgvector die richtige erste Antwort. Wechsle zu Qdrant, wenn du ihm entwachsen bist, nicht vorher.

Die RAM-Realität (das ist der Teil, den Leute unterschätzen)

Vektorsuche ist schnell, weil der Index im Speicher lebt — also ist RAM, nicht Platz, deine echte Einschränkung. Ein grober Leitfaden:

Ein paar hunderttausend Embeddings — bequem in 2 GB.
Niedrige Millionen — plane 4 GB+ und tune den Index.
Platz ist der einfache Teil: eine Million Embeddings sind nur ein paar GB, also decken 25–45 GB einen ernsthaften Speicher.

Dimensioniere also für den Index, nicht für die Datei. (Dieselbe Logik wie im allgemeinen Dimensionierungsleitfaden — das Schwere ist nicht offensichtlich, bis du misst.)

Schnellstart: pgvector

Auf einer Maschine mit Postgres (Docker ist am einfachsten — dasselbe Muster wie beim Selbst-Hosten von 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);

Dein Agent fügt content + sein Embedding ein, dann fragt er mit ORDER BY embedding <=> $query_embedding LIMIT 5 ab, um die nächstgelegenen Erinnerungen zu ziehen. Das ist die ganze Schleife.

Bevorzugst du Qdrant? Es ist ein einzelner Docker-Container, der eine HTTP/gRPC-API bereitstellt; du erstellst eine Collection mit deiner Vektorgröße und upsertest Punkte. Dieselbe Idee, dedizierte Engine.

Kann sie sich eine Maschine mit dem Agenten teilen?

Ja — für kleine bis mittlere Gedächtnisspeicher betreibe die Vektor-DB auf demselben VPS wie den Agenten. Es ist einfacher und die Latenz ist praktisch null. Trenne sie nur auf separate Server, wenn einer beginnt, den anderen aus dem RAM zu drängen. Das ist eine spätere, schöne-Probleme-Entscheidung, keine von Tag eins.

Ehrliche Einschränkungen

RAM ist die Wand, und sie ist leise. Die Suche bleibt schnell, bis der Index nicht mehr in den Speicher passt, dann degradiert sie. Beobachte den Speicher und skaliere, bevor es beißt — warte nicht, bis langsame Abfragen es dir sagen.
Embeddings kosten Tokens zum Erstellen. Jedes Dokument, das du einbettest, ist ein API-Aufruf an ein Embedding-Modell. Der Speicher ist günstig zu hosten; die Vektoren zu generieren ist die wiederkehrende Kosten — relevant für was der Betrieb eines Agenten tatsächlich kostet.
Sichere sie. Das Gedächtnis deines Agenten sind Daten wie alle anderen. Wenn es wichtig ist, mach einen Snapshot.

Innerhalb dessen ist ein selbst gehosteter Vektorspeicher ein sauberer Weg, einem Agenten ein dauerhaftes Gedächtnis zu geben, ohne deine privaten Daten an einen Dritten zu übergeben. Starte mit pgvector auf einer 2-GB-Maschine, behalte den RAM im Auge und wachse erst in Qdrant oder einen größeren Plan hinein, wenn die Zahlen es dir sagen.