Wer eine semantische Suche, Empfehlungen oder Retrieval-Augmented Generation baut, braucht einen Ort für Embeddings — Zahlenvektoren, die die Bedeutung von Texten oder Bildern abbilden. Die Wahl fällt meist zwischen zwei Wegen: die Erweiterung pgvector in einer bestehenden PostgreSQL-Datenbank oder ein spezialisierter Dienst, der nur für Vektoren gebaut ist. Für viele SaaS-Produkte ist die richtige Antwort weniger spektakulär, als Marketingmaterial vermuten lässt.
Was pgvector ist
pgvector ergänzt PostgreSQL um einen Datentyp für Vektoren und um Operatoren für Ähnlichkeitssuche, etwa über Kosinus-Distanz. Vektoren liegen damit in derselben Tabelle wie die übrigen Daten eines Datensatzes. Für schnelle Suchen über grössere Datenmengen bietet die Erweiterung Näherungsindexe an, darunter HNSW, das eine gute Balance aus Suchgeschwindigkeit und Trefferqualität bietet. Plattformen wie Supabase stellen pgvector ohne zusätzliche Infrastruktur bereit.
Der grösste Vorteil: alles an einem Ort
In einem SaaS-Produkt ist die Vektorsuche fast nie eine reine Ähnlichkeitssuche. Sie muss gefiltert werden: nur Dokumente dieses Mandanten, nur Inhalte, die der angemeldete Nutzer sehen darf, nur Einträge einer bestimmten Kategorie oder eines Zeitraums. In PostgreSQL ist das eine normale Abfrage mit Bedingungen, und Row-Level-Security gilt für die Vektoren genauso wie für alle anderen Daten. Die Mandantentrennung, die man ohnehin gebaut hat, schützt automatisch auch die semantische Suche.
Dazu kommt Konsistenz. Wird ein Dokument gelöscht oder geändert, verschwindet oder ändert sich der Vektor in derselben Transaktion. Bei einer separaten Vektordatenbank muss dieser Abgleich zusätzlich gebaut und überwacht werden — und ein vergessener Löschvorgang bedeutet, dass gelöschte Inhalte weiterhin in Suchergebnissen oder KI-Antworten auftauchen. Für Auskunfts- und Löschbegehren nach DSGVO ist das kein Detail.
Wo pgvector an Grenzen stösst
Näherungsindexe brauchen Arbeitsspeicher, und ihr Aufbau kostet bei grossen Datenmengen Zeit. Wer sehr grosse Vektorbestände mit hoher Abfragelast betreibt, konkurriert mit dem übrigen Datenbankbetrieb um Ressourcen. Kombiniert man strenge Filter mit einem Näherungsindex, kann die Trefferqualität sinken, wenn der Index zuerst nach Ähnlichkeit sucht und der Filter danach viele Treffer verwirft; neuere Versionen der Erweiterung verbessern das, es bleibt aber ein Punkt, den man testen muss.
Dedizierte Vektordatenbanken sind auf genau diese Lasten ausgelegt: verteilte Indexe, Filter, die in die Suche integriert sind, und Skalierung unabhängig von der Hauptdatenbank. Sie lohnen sich, wenn Vektorsuche der Kern des Produkts ist, die Datenmengen weit über das hinausgehen, was eine einzelne Datenbankinstanz gut trägt, oder wenn die Suchlast den übrigen Betrieb spürbar belastet.
Die Fragen, die die Wahl entscheiden
Erstens: Wie viele Vektoren werden es realistisch in den nächsten zwei Jahren, nicht im optimistischsten Szenario? Zweitens: Wie streng und wie vielfältig sind die Filter? Drittens: Wie wichtig ist Konsistenz mit den übrigen Daten, etwa für Löschungen und Berechtigungen? Viertens: Wer betreibt das System, und wie viel zusätzliche Infrastruktur kann das Team verantworten? Für die meisten B2B-SaaS mit mandantenbezogenen Dokumentenbeständen sprechen die Antworten für PostgreSQL.
Praxis mit pgvector
Einige Punkte machen in der Praxis den Unterschied. Die Dimension der Vektoren hängt vom Embedding-Modell ab und sollte bei einem Modellwechsel nicht mit alten Vektoren vermischt werden; eine Spalte für die Modellversion erleichtert die Migration. Der HNSW-Index hat Parameter, die Suchgeschwindigkeit gegen Trefferqualität abwägen, und diese sollten mit echten Abfragen und einem kleinen Bewertungsdatensatz eingestellt werden, nicht nach Gefühl. Für sehr selektive Filter, etwa die Dokumente eines einzelnen kleinen Mandanten, ist manchmal eine exakte Suche ohne Index schneller und genauer.
Hilfreich ist ausserdem eine hybride Suche: Vektorsuche kombiniert mit klassischer Volltextsuche, die PostgreSQL ebenfalls mitbringt. Gerade bei deutschen Texten mit zusammengesetzten Wörtern, Produktnamen oder Artikelnummern findet die Volltextsuche Treffer, die eine reine Bedeutungssuche verfehlt.
Migration offen halten
Wer mit pgvector startet, legt sich nicht für immer fest. Wenn die Suchlogik hinter einer klaren Schnittstelle im eigenen Code liegt, lässt sich später eine dedizierte Vektordatenbank anbinden, ohne das Produkt umzubauen. Der umgekehrte Weg — von einer separaten Vektordatenbank zurück in PostgreSQL — ist ebenso möglich, aber selten nötig, wenn man von Anfang an realistisch geplant hat.
Unsere Empfehlung
Für SaaS-Produkte, deren Vektorsuche Dokumente, Tickets oder Wissensbasen einzelner Mandanten durchsucht, ist pgvector in PostgreSQL in aller Regel die bessere Wahl: weniger Infrastruktur, Berechtigungen und Konsistenz ohne Zusatzaufwand, und eine Hauptdatenbank, die das Team ohnehin kennt. Eine dedizierte Vektordatenbank ist dann richtig, wenn Messungen zeigen, dass die Last oder die Datenmenge die Datenbank tatsächlich überfordert. Innopulse setzt in eigenen Produkten auf Supabase mit pgvector und hilft Teams, diese Entscheidung auf Basis von Messungen statt Annahmen zu treffen.