Vektorsearch in Produktion: pgvector vs. dedizierte Vektordatenbanken

Ein SaaS-Team in Hamburg verbrachte letztes Quartal drei Wochen damit, pgvector vs. Pinecone, Weaviate und Qdrant fuer eine 4-Millionen-Chunk-Wissensbasis zu benchmarken. Engineering favorisierte Pinecone, weil die Docs am freundlichsten waren. Platform favorisierte Qdrant, weil die Lizenz stimmte. Der CTO wollte Postgres aus demselben Grund, aus dem jeder CTO Postgres will: ein System weniger, das man im Auge behalten muss. Die Entscheidung lag vierzig Tage lang auf einer Confluence-Seite, waehrend ein Feature, das mit pgvector an einem langen Wochenende haette ausgeliefert werden koennen, exakt null Umsatz erzielte. Als sie schliesslich ihre tatsaechliche Arbeitslast masssen - 4 Millionen Chunks, ca. 6 QPS im Peak, sub-300 ms p95 akzeptabel - gewann pgvector in jeder Dimension, die zaehlt. Die Lieferantenbewertung war eine Steuer, die fuer die vorgestellte Version des Systems bezahlt wurde, nicht die echte.

Dieser Beitrag ist der Vergleich, den dieses Team zuerst haette lesen sollen. Es ist keine Feature-Matrix, die von Anbieter-Landingpages abgekratzt wurde; es ist ein lastgesteuerter Blick auf Vektorsuch-Produktions-Tradeoffs, mit konkreten Schwellenwerten, wann pgvector die richtige Antwort ist und wann eine dedizierte Vektordatenbank ihren Betriebsaufwand verdient. Der Standard in 2026 sollte Postgres mit pgvector sein, und man sollte den Wechsel zu allem anderen mit Zahlen begrnden koennen.

Was die Entscheidung wirklich treibt

Die meisten Vektordatenbank-Vergleichsbeitraege ranken die Konkurrenten nach Benchmarks, die keiner ihrer Leser erreichen wird. Die Variablen, die fuer ein echtes Produkt zaehlen, sind enger und langweiliger.

Corpus-Groesse. Wie viele Vektoren muessen indexiert werden, und wie schnell wachst diese Zahl? Ein paar Hunderttausend Chunks ist Hobby-Scale. Ein paar Millionen ist das Fleisch des B2B-SaaS. Zehn Millionen ist die Schwelle, wo das Spiel sich aendert. Darueber beginnt man, ernsthaft auf Speicher-Layout und Festplatten-I/O zu achten.

Abfragerate und Latenz-Budget. Ein Backoffice-"Durchsuche unsere Dokumente"-Feature sieht 1-5 QPS im Peak mit einem 500-ms-Latenz-Budget. Eine nutzerorientierte Autovervollstaendigung, die an Embeddings gebunden ist, sieht Hunderte QPS mit einem 50-ms-Budget. Das sind verschiedene Probleme mit verschiedenen Antworten, selbst auf demselben Corpus.

Update-Kadenz. Ein statischer juristischer Corpus, der sich monatlich aendert, ist ein anderes System als ein Kunden-Support-Index, der sich jede Minute aendert. Echtzeit-Index-Updates aendern das Kalkuel auf HNSW (das teuer neu zu bauen ist) vs. IVFFlat (das billiger aber weniger genau ist).

Filter-Selektivitaet. Fast jede Produktionsabfrage hat Metadaten-Filter - Tenant, Sprache, Dokumenttyp, Datumsbereich. Je enger der Filter, desto akzeptabler werden Brute-Force-Scans. Je lockerer der Filter, desto mehr haengt man von einem schnellen approximativen Index ab.

Betriebliche Realitaet. Man betreibt bereits Postgres. Man betreibt wahrscheinlich bereits Redis. Einen vierten zustandsbehafteten Dienst zur Plattform hinzuzufuegen ist nicht kostenlos, und die Kosten sind meist unsichtbar, bis sonntags um 03:00 Uhr etwas kaputt geht.

Diese fuenf Variablen, nicht die Marketing-Seiten-Benchmarks, entscheiden, welches Tool passt.

pgvector: Wo Postgres-Vektorsearch gewinnt

Die pgvector-Extension verwandelt Postgres in einen kompetenten Vektorspeicher mit HNSW- und IVFFlat-Indizes, Cosinus-, L2- und Inner-Product-Distanz und vorhersagbarer Leistung bis zu etwa 50 Millionen Zeilen auf handelsueblicherHardware. Fuer die meisten B2B-SaaS-Workloads liegt diese Decke mehrere Jahre ueber dem aktuellen Stand des Produkts.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunk (
    id BIGSERIAL PRIMARY KEY,
    tenant_id UUID NOT NULL,
    document_id UUID NOT NULL,
    content TEXT NOT NULL,
    embedding vector(1536),
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX chunk_tenant_idx ON chunk (tenant_id);
CREATE INDEX chunk_embedding_idx
    ON chunk USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

Ein Single-Row-Schema, zwei Indizes, und man hat einen tenant-bewussten Vektorspeicher, der von der Datenbank gestuetzt wird, der die Anwendung bereits vertraut. Die Gewinne verstaerken sich in Produktion.

Transaktionale Konsistenz ist der groesste. Wenn man ein neues Dokument einbettet, schreibt man das Dokument, die Chunks und die Vektoren in einer Transaktion. Es gibt keine letztendliche Konsistenz zwischen der Wahrheitsquelle und dem Vektorspeicher, keinen Synchronisierungsjob, um Drift auszugleichen, und kein Szenario, in dem die Anwendung einen Chunk sieht, den der Index noch nicht kennt. Teams, die eine separate Vektordatenbank betrieben haben, wissen, wie viel Engineering darin fliesst, so zu tun, als ob diese Konsistenz existiert.

Filter-Pushdown ist der zweite. Postgres weiss, wie man einen HNSW-Scan mit einem B-Tree-Index auf tenant_id oder language kombiniert, besser als die meisten dedizierten Systeme. Mit pgvector 0.7+ und der iterative-Scan-Option hoeren sehr selektive Filter auf, eine Gefahr zu sein. Fuer multi-tenant SaaS eliminiert diese einzelne Eigenschaft eine ganze Kategorie von Vendor-Lock-in.

Betriebliche Passform ist der dritte. Backups, Monitoring, Point-in-Time-Recovery, Replicas, Zugangskontrolle - all das deckt Vektorsearch ab dem Tag ab, an dem man das Feature ausliefert. Es gibt kein separates Dashboard, kein separates IAM-Modell, keine zweite Oncall-Rotation.

Wo pgvector duenner wird: Corpora ueber ca. 50 Millionen Chunks, wo die HNSW-Speicherkosten unbequem werden, anhaltende Lasten ueber ein paar hundert QPS pro Primary, Multi-Vektor-Retrieval (ColBERT-Stil), das Architektur erfordert, die pgvector nativ nicht unterstuetzt, und Modelle mit sehr hohen Dimensionen (3072+), bei denen die Index-Qualitaet abnimmt. Das sind die echten Grenzen. Fast kein B2B-SaaS erreicht sie.

Pinecone, Weaviate, Qdrant: Was man wirklich bekommt

Die drei dedizierten Systeme sind nicht austauschbar, und sie zu vermischen ist der haeufigste Fehler in Lieferantenbewertungen.

Pinecone ist die nur-managed Option. Man uebergibt ihnen Vektoren und Abfragen; sie geben Ergebnisse mit vorhersagbarer Latenz zurueck. Das Preismodell ist pro Pod, die Betriebsgeschichte ist "es gibt keine Betriebsgeschichte," und die Time-to-Feature ist exzellent. Die Kosten sind der Kontrollverlust: kein Self-Hosting, US-Datenspeicherort ausser man zahlt fuer den EU-Tier, und die Art von Vendor-Lock-in, die zu einer Vorstandsdiskussion wird, wenn die Rechnung waechst. Pinecone macht Sinn, wenn das Team null Infrastruktur-Kapazitaet hat und die Daten nicht DSGVO-sensibel sind.

Weaviate ist das funktionsreichste. Eingebaute Hybrid-Suche (BM25 + Vektoren), modulare Einbetter, die innerhalb der Datenbank laufen koennen, Multi-Tenancy, GraphQL- und REST-APIs. Die Cloud-Option ist real und die Self-Hosted-Option funktioniert. Die Kosten sind die konzeptuelle Oberflaeche: Weaviate ist eine Datenbank an sich, und es als "nur ein Vektorspeicher" zu behandeln laesst Leistung auf dem Tisch liegen. Weaviate macht Sinn, wenn Hybrid-Suche und enge Embedding-Integration wichtiger sind als Schema-Einfachheit.

Qdrant ist die Leistungs-und-Kontroll-Option. In Rust geschrieben, sehr schnell, starke Filter-Leistung, eine Apache-2.0-Lizenz und eine saubere Self-Hosted-Geschichte. Die Cloud-Option ist in Ordnung; die Self-Hosted-Option ist, was die meisten Qdrant-Nutzer wirklich betreiben. Die Kosten sind, dass man jetzt einen zustandsbehafteten Dienst betreibt, ueber den niemand im Team nachts wacht. Qdrant macht Sinn, wenn Rohleistung zaehlt und das Team die Plattform-Muskeln hat, es gut zu betreiben.

Fuer europaeische Kunden ist ein unterschaetzter Faktor der Datenspeicherort. Qdrant selbst gehostet in der eigenen Infrastruktur ist die einfachste DSGVO-Geschichte; Weaviate mit EU-Hosting ist vernuenftig; Pinecone EU ist machbar, aber teurer und gebundener. Ein pgvector-Setup auf einem Hetzner- oder OVH-Postgres benoetigt ueberhaupt keine separate Pruefung.

Die Zahlen, die die Wahl treffen sollten

Ein Tool nach der Last auswaehlen, die es tragen muss, nicht nach der Last, die man sich eines Tages vorstellt. Die untenstehenden Schwellenwerte stammen aus Produktions-Deployments, die wir auditiert und gebaut haben; behandeln Sie sie als Ausgangspunkte, nicht als Gesetze.

Bei pgvector bleiben, wenn der Corpus unter 20 Millionen Chunks liegt, der Peak-QPS unter 100 liegt, die Update-Rate moderat ist (unter ein paar tausend Vektoren pro Minute) und die Filter selektiv sind. Das deckt die ueberwiegende Mehrheit der B2B-SaaS-Wissensbasen, der internen Suche und der RAG-Features ab.

Qdrant in Betracht ziehen, wenn der Corpus zwischen 20 und 200 Millionen Chunks liegt, man sub-50-ms p99 bei dreistelligen QPS braucht und Engineers hat, die es betreiben koennen. Selbst gehostetes Qdrant auf einer seriosen VM mit NVMe-Speicher haelt sich bei dieser Groessenordnung beeindruckend, und die Kostengeschichte schlaegt Pinecone deutlich.

Weaviate in Betracht ziehen, wenn Hybrid-Suche eine erstklassige Anforderung ist, man Embedding-Modell-Logik innerhalb der Datenbank behalten moechte oder eine GraphQL-API braucht, um ein Frontend zu speisen ohne einen eigenen Dienst zu schreiben.

Pinecone in Betracht ziehen, wenn das Team null Kapazitaet hat, einen weiteren zustandsbehafteten Dienst zu betreiben, DSGVO kein Problem ist (oder der EU-Tier ins Budget passt) und das Feature naechsten Monat auszuliefern wichtiger ist als die Pro-Abfrage-Kosten.

Der ehrliche Schwellenwert, um pgvector zu verlassen, ist selten "wir haben 50 Millionen Vektoren erreicht." Es ist ueblicherweise "der Engpass hat sich von Retrieval-Qualitaet zu Retrieval-Latenz verschoben, wir haben es gemessen und billigere Korrekturen ausgeschlossen." Viel Geld wurde fuer dedizierte Vektordatenbanken von Teams ausgegeben, die die gleiche Luecke mit einem besseren Re-Ranker, intelligentetem Chunking oder einer HNSW-Parameter-Aenderung haetten schliessen koennen.

Ein Entscheidungsframework fuer die Vektordatenbank-Auswahl

Eine kurze Checkliste ist nuetzlicher als eine weitere Benchmark-Tabelle. Gehen Sie sie beim naechsten Mal durch, wenn jemand ein Pinecone-vs-Weaviate-vs-Qdrant-Meeting plant.

Liegt der Corpus heute unter 20 Millionen Chunks und ist unwahrscheinlich, sich in den naechsten zwoelf Monaten zu verdreifachen? Liegt der Peak-QPS unter 100? Sind die Filter-Klauseln selektiv? Ist die Datensensibilitaet hoch genug, dass das Bleiben auf einem EU-gehosteten Postgres ein harter Gewinn ist? Betreibt das Team bereits Postgres in Produktion? Wenn fuenf von fuenf ja sind, ist pgvector die Antwort und das Meeting ist vorbei.

Wenn die Antwort bei Corpus oder QPS nein ist, einen echten Benchmark auf repraesentativen Daten und Traffic gegen die Top-ein oder -zwei Alternativen ausfuehren - nicht alle drei. Entscheidung auf Zahlen treffen: p95-Retrieval-Latenz, Recall@10 gegenueber einem kuratierten Eval-Set, monatliche Kosten bei projiziertem Volumen und eine realistische Schaetzung der Platform-Engineering-Stunden pro Quartal.

Dann sich festlegen. Die Teams, die bei dieser Entscheidung hin- und hergerissen sind, zahlen ueblicherweise mehr durch verzoegerte Auslieferung als sie an Infrastrukturkosten jemals einsparen konnten.

Migration: Wie man ohne Drama wechselt

Wenn ein Benchmark sagt, man muss wirklich pgvector verlassen, ist die Migration ein unkomplizierter zweiphasiger Rollout. pgvector als Wahrheitsquelle behalten, Embeddings hinter einem Feature-Flag in das neue System dual-schreiben, beide Retriever eine Woche lang im Shadow-Mode mit protokollierten Vergleichs-Metriken laufen lassen, dann den Traffic umschalten. Das neue System uebernimmt das Retrieval; pgvector bleibt weiterhin der konsistente kanonische Speicher.

Dasselbe Blueprint funktioniert umgekehrt. Wir haben europaeischen Teams geholfen, von einer managed Vektordatenbank zurueck zu pgvector zu migrieren, nachdem die Rechnung, das Latenz-Profil und der DSGVO-Review in eine Richtung ausgerichtet waren. Diese Art von pragmatischem Rueckschritt ist Teil gesunder Legacy-Code-Optimierung, selbst wenn der "Legacy"-Code zwoelf Monate alt ist.

Was man mitnehmen sollte

Der Standard fuer Vektorsuch-Produktion bei den meisten B2B-SaaS-Skalierungen ist Postgres mit pgvector. Es eliminiert ein Synchronisierungsproblem, passt zur Betriebsform eines Teams, das bereits Postgres betreibt, und haelt Lasten stand, die die meisten Produkte nicht ueberschreiten werden. Dedizierte Vektordatenbanken verdienen ihren Platz ueber klaren Schwellenwerten, und die richtige haengt davon ab, ob man fuer managed Einfachheit (Pinecone), Feature-Reichhaltigkeit (Weaviate) oder Rohleistung mit Kontrolle (Qdrant) optimiert.

Einen Stack auf echten Zahlen auswaehlen - Corpus-Groesse, QPS, Update-Kadenz, Filter-Selektivitaet und die Betriebsmannschaft, die man wirklich hat - ist dramatisch billiger als einen auf Anbieter-Charisma auszuwaehlen. Wenn man Vektordatenbank-Optionen fuer ein reguliertes europaeisches Produkt bewertet oder ein Vektorsuch-System rettet, dessen Kosten und Latenzen ueber den Komfortpunkt hinaus gedriftet sind, ist das die Art von Architektur-Review, fuer die ein Tech-Stack-Strategie-Engagement gebaut ist. Kontaktieren Sie uns unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io, um den richtigen Vektorspeicher fuer Ihre Arbeitslast zu besprechen.