Vektor-Datenbanken: pgvector, Qdrant, Vectorize im Vergleich

Warum eine normale Datenbank hier nicht reicht

Ein Embedding ist ein Vektor mit hunderten bis tausenden Zahlen, der die Bedeutung eines Texts, Bilds oder Audioclips numerisch codiert. Aehnliche Inhalte liegen im Vektorraum nahe beieinander. Genau das macht “semantische Suche” moeglich: Statt nach exakten Wortuebereinstimmungen zu suchen, suchst du nach Naehe im Bedeutungsraum.

Das Problem: Eine klassische Datenbank mit WHERE-Klauseln oder B-Tree-Index ist fuer diese Art von Suche nicht gebaut. Du willst nicht “finde Zeilen, bei denen Spalte X gleich Y ist”, sondern “finde die 10 Vektoren, die einem gegebenen Vektor am naehesten liegen” — bei Millionen von Eintraegen und Vektoren mit 384, 768 oder 1536 Dimensionen. Ein simpler Scan, der die Distanz zu jedem einzelnen Vektor berechnet (Brute Force bzw. kNN exakt), skaliert linear mit der Datenmenge und wird ab ein paar hunderttausend Eintraegen spuerbar langsam.

Vektor-Datenbanken loesen genau dieses Problem: Sie speichern Vektoren zusammen mit Metadaten, bieten spezialisierte Indizes fuer schnelle Aehnlichkeitssuche und liefern in Millisekunden die naechsten Nachbarn zurueck — auch bei zig Millionen Eintraegen. Dieser Artikel baut auf Embeddings und Vektoren erklaert auf und zeigt, wie du fuer RAG-Systeme die richtige Vektor-DB auswaehlst.

Aehnlichkeitssuche: Distanzmasse verstehen

Bevor es um konkrete Produkte geht, lohnt sich ein Blick auf die Mathematik dahinter. Die drei gebraeuchlichsten Distanz- bzw. Aehnlichkeitsmasse:

Fast alle modernen Embedding-Modelle normalisieren ihre Vektoren auf Laenge 1. In diesem Fall sind Cosine Similarity und inneres Produkt mathematisch aequivalent — ein Grund, warum viele Vektor-DBs beide Optionen anbieten, ohne dass es in der Praxis einen grossen Unterschied macht.

Der Index: warum HNSW der De-facto-Standard ist

Der Kern jeder Vektor-Datenbank ist ihr Approximate Nearest Neighbor-Index (ANN). “Approximate” heisst: Statt garantiert die exakt naehesten Vektoren zu finden, liefert der Index mit sehr hoher Wahrscheinlichkeit die naehesten Vektoren — im Austausch gegen einen massiven Geschwindigkeitsgewinn. Bei Millionen Vektoren ist dieser Kompromiss fast immer richtig: Ein exakter Scan waere um Groessenordnungen langsamer, fuer eine minimal geringere Trefferquote.

HNSW (Hierarchical Navigable Small World) hat sich als Standard-Indexstruktur durchgesetzt und wird von pgvector, Qdrant, Pinecone und den meisten anderen Vektor-DBs eingesetzt. Die Grundidee:

• Vektoren werden in mehreren uebereinanderliegenden “Schichten” mit einem Graphen verbunden — je hoeher die Schicht, desto weniger Knoten, aber desto weiter reichen die Verbindungen.
• Eine Suche startet oben in einer duennen Schicht, springt schnell in die grobe Naehe des Zielbereichs, und steigt dann Schicht fuer Schicht ab, wo die Suche immer feiner wird.
• Das Ergebnis: Suchzeit waechst nur logarithmisch mit der Datenmenge, nicht linear.

Die wichtigsten Stellschrauben, die in praktisch jeder HNSW-Implementierung auftauchen:

Eine aeltere, aber immer noch verbreitete Alternative ist IVFFlat (Inverted File Flat): Die Datenmenge wird in Cluster (“Listen”) unterteilt, und eine Suche durchsucht nur die vielversprechendsten Cluster statt aller Daten. IVFFlat baut deutlich schneller als HNSW und braucht weniger Speicher, liefert bei gleicher Geschwindigkeit aber tendenziell schlechtere Suchqualitaet. Fuer die meisten neuen Projekte ist HNSW heute die bessere Wahl — IVFFlat lohnt sich vor allem bei sehr grossen Datenmengen mit engem Speicherbudget.

Die vier Kandidaten im Vergleich

pgvector — die Postgres-Erweiterung

pgvector macht aus einer normalen PostgreSQL-Datenbank eine Vektor-Datenbank, indem es einen neuen Datentyp (vector) und passende Indizes hinzufuegt. Der grosse Vorteil: Vektoren leben direkt neben deinen relationalen Daten in derselben Datenbank — keine zweite Infrastruktur, keine Synchronisation zwischen zwei Systemen, volle SQL-Power (Joins, Transaktionen, Foreign Keys) kombiniert mit Aehnlichkeitssuche.

-- pgvector: Tabelle mit Embedding-Spalte anlegen (Stand: pgvector 0.8.x)
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE dokumente (
    id bigserial PRIMARY KEY,
    inhalt text,
    embedding vector(1536)
);

-- HNSW-Index fuer Cosine-Distanz
CREATE INDEX ON dokumente
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- Die 5 aehnlichsten Dokumente zu einem gegebenen Vektor finden
SELECT id, inhalt, embedding <=> '[0.012, -0.034, ...]'::vector AS distanz
FROM dokumente
ORDER BY embedding <=> '[0.012, -0.034, ...]'::vector
LIMIT 5;

pgvector unterstuetzt mehrere Distanzoperatoren direkt in SQL: <-> (L2), <#> (inneres Produkt), <=> (Cosinus), sowie <+> (L1) und binaere Varianten fuer Hamming-/Jaccard-Distanz. Seit Version 0.7 gibt es zusaetzlich den Typ halfvec (Vektoren mit halber Praezision, bis 4000 Dimensionen, spart Speicher) und seit 0.8 iterative Index-Scans, die bei kombinierter Vektor- und Metadatenfilterung (z.B. “aehnlichste Dokumente, aber nur aus Abteilung X”) deutlich zuverlaessigere Ergebnisse liefern als vorher.

Qdrant — die spezialisierte Vektor-DB

Qdrant ist eine in Rust geschriebene, dedizierte Vektor-Datenbank mit Fokus auf Performance und reichhaltige Filterfunktionen. Sie laesst sich selbst hosten (Open Source, Docker-Image) oder als Managed-Service (Qdrant Cloud) mit einem kostenlosen Einstiegs-Cluster (Stand: 2026-07, ca. 1 GB RAM) nutzen.

# Qdrant Python-Client: Collection anlegen und Vektor einfuegen
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct

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

client.create_collection(
    collection_name="dokumente",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

client.upsert(
    collection_name="dokumente",
    points=[
        PointStruct(
            id=1,
            vector=[0.012, -0.034, ...],
            payload={"abteilung": "vertrieb", "sprache": "de"},
        )
    ],
)

# Suche mit Metadaten-Filter kombiniert
treffer = client.query_points(
    collection_name="dokumente",
    query=[0.011, -0.030, ...],
    query_filter={"must": [{"key": "abteilung", "match": {"value": "vertrieb"}}]},
    limit=5,
)

Qdrants Staerken: eingebaute Quantisierung (Vektoren komprimiert im Speicher halten, um RAM zu sparen), sehr flexible Filter (verschachtelte Bedingungen, Geo-Filter, Volltextfilter kombiniert mit Vektorsuche) und horizontale Skalierung ueber Sharding. Fuer Projekte mit komplexen Filterbeduerfnissen oder sehr grossen Datenmengen ist Qdrant oft die leistungsfaehigere Wahl gegenueber pgvector.

Pinecone — vollstaendig verwalteter Service

Pinecone war einer der ersten reinen “Vector-Database-as-a-Service”-Anbieter und bleibt eine verbreitete Wahl, wenn du dich um Infrastruktur ueberhaupt nicht kuemmern willst. Es gibt keine Selbsthosting-Option — Pinecone ist ausschliesslich als Cloud-Service verfuegbar.

# Pinecone Python-Client: Index anlegen und abfragen (Serverless)
from pinecone import Pinecone

pc = Pinecone(api_key="dein-api-key")

index = pc.Index("dokumente")

index.upsert(vectors=[
    {"id": "doc-1", "values": [0.012, -0.034, ...], "metadata": {"abteilung": "vertrieb"}}
])

ergebnis = index.query(
    vector=[0.011, -0.030, ...],
    top_k=5,
    filter={"abteilung": {"$eq": "vertrieb"}},
    include_metadata=True,
)

Pinecones “Serverless”-Modell rechnet nach tatsaechlicher Nutzung ab (Lese-/Schreib-Einheiten plus Speicher), mit einem kostenlosen Einstiegsplan und einer monatlichen Mindestgebuehr auf den bezahlten Stufen (Stand: 2026-07, rund 50 USD/Monat). Neben dichten Vektor-Indizes unterstuetzt Pinecone inzwischen auch Sparse- und Volltext-Indizes sowie eingebaute Rerank-Modelle — nuetzlich, wenn du Vektorsuche mit klassischer Stichwortsuche kombinieren willst (Hybrid Search).

Cloudflare Vectorize — die Edge-native Option

Vectorize ist Cloudflares Vektor-DB, gebaut fuer die Kombination mit Workers und Workers AI. Der grosse Pluspunkt: keine separate Infrastruktur, keine Netzwerklatenz zu einem externen Anbieter — die Vektorsuche laeuft im selben Edge-Netzwerk wie dein Worker.

// Cloudflare Worker: Vectorize-Index abfragen
export default {
  async fetch(request, env) {
    const anfrageEmbedding = await env.AI.run("@cf/baai/bge-base-en-v1.5", {
      text: ["Wie kuendige ich meinen Vertrag?"],
    });

    const treffer = await env.VECTORIZE.query(anfrageEmbedding.data[0], {
      topK: 5,
      returnMetadata: true,
    });

    return Response.json(treffer.matches);
  },
};

# Vectorize-Index per Wrangler CLI anlegen
npx wrangler vectorize create dokumente-index --dimensions=1536 --metric=cosine

Wichtige Limits (Stand: 2026-07): bis zu 1536 Dimensionen pro Vektor, bis zu 10 Millionen Vektoren pro Index, Metadaten bis 10 KiB pro Vektor mit maximal 10 filterbaren Metadaten-Feldern pro Index. Abgerechnet wird nach “Vektor-Dimensionen” statt nach Vektoren: Der Workers-Free-Plan enthaelt 30 Millionen abgefragte und 5 Millionen gespeicherte Vektor-Dimensionen pro Monat kostenlos, auf dem Paid-Plan sind es 50 bzw. 10 Millionen, danach centbetraege pro weitere Million.

Vergleichstabelle

Entscheidungsbaum

Brauchst du Vektorsuche zusammen mit relationalen Daten
(Joins, Transaktionen, bestehendes Schema)?
├─ Ja, und Postgres ist schon im Einsatz
│   → pgvector
│
├─ Nein / eigenstaendiges System ist ok
│   │
│   ├─ Willst du selbst hosten oder volle Kontrolle ueber Infrastruktur?
│   │   → Qdrant (self-hosted) oder Qdrant Cloud
│   │
│   ├─ Bereits im Cloudflare-Stack (Workers, D1, Workers AI)?
│   │   → Cloudflare Vectorize
│   │
│   └─ Reine SaaS-Loesung ohne eigene Infrastruktur gewuenscht,
│      ausserhalb von Cloudflare?
│       → Pinecone (oder Qdrant Cloud als Alternative)

Praxis: Metadaten-Filter kombiniert mit Vektorsuche

In echten Anwendungen willst du fast nie “die 5 aehnlichsten Vektoren im ganzen Index”, sondern “die 5 aehnlichsten Vektoren, die zusaetzlich bestimmte Bedingungen erfuellen” — z.B. nur Dokumente einer bestimmten Abteilung, eines bestimmten Datumsbereichs oder mit einer bestimmten Zugriffsberechtigung. Diese Kombination aus Vektorsuche und klassischem Filter heisst Hybrid Filtering und ist in der Praxis fast immer noetig, gerade bei mandantenfaehigen Systemen (Multi-Tenancy).

Alle vier vorgestellten Loesungen unterstuetzen das, mit unterschiedlicher Tiefe:

• pgvector: normale SQL-WHERE-Klausel neben der ORDER BY ... <=> ...-Sortierung — am flexibelsten, weil es echtes SQL ist.
• Qdrant: eigenes Filter-DSL mit verschachtelten must/should/must_not-Bedingungen, inklusive Geo- und Volltextfiltern.
• Pinecone: JSON-basierte Metadatenfilter mit MongoDB-aehnlicher Syntax ($eq, $in, $gte usw.).
• Vectorize: einfache Gleichheits-/Bereichsfilter auf bis zu 10 indizierten Metadatenfeldern pro Index.

Kurz zusammengefasst

• Vektor-Datenbanken loesen Aehnlichkeitssuche im hochdimensionalen Raum, wo klassische Indizes (B-Tree) nicht helfen.
• HNSW ist der De-facto-Standard-Index: logarithmische statt lineare Suchzeit, mit den Stellschrauben m, ef_construction und ef_search.
• pgvector passt am besten, wenn Postgres schon im Einsatz ist und du SQL-Joins mit Vektorsuche kombinieren willst.
• Qdrant eignet sich fuer grosse Datenmengen und komplexe Filteranforderungen, self-hosted oder als Managed Cloud.
• Pinecone ist die reine SaaS-Option ohne eigene Infrastruktur, mit eingebautem Hybrid Search.
• Cloudflare Vectorize passt am besten innerhalb des Cloudflare-Stacks (Workers, D1, Workers AI).
• Distanzmass und Chunking-Strategie beeinflussen die Suchqualitaet mindestens so stark wie die Wahl der Datenbank selbst.

Weiterlernen

• pgvector auf GitHub — offizielles Repository mit vollstaendiger Feature-Liste
• Qdrant-Dokumentation — Konzepte, Filter, Quantisierung, Deployment
• Pinecone-Dokumentation — Serverless-Architektur, Hybrid Search, Preise
• Cloudflare Vectorize-Dokumentation — Limits, API, Integration mit Workers AI
• Pinecone: Was ist ein Vektor-Index? (HNSW erklaert) — vertiefende Erklaerung der HNSW-Algorithmik

Verwandte Themen: Embeddings und Vektoren erklaert · RAG selbst bauen · Cloudflare Workers AI · LLM-APIs: Grundlagen