Die Kernfrage
Seit RAG und semantische Suche zum Standard-Werkzeugkasten gehören, taucht die Frage in fast jedem Projekt auf: Brauchen wir jetzt eine Vektordatenbank – und was passiert dann mit unserer SQL-Datenbank?
Die kurze Antwort: Die beiden lösen unterschiedliche Probleme.
- SQL-Datenbank: exakte, strukturierte Abfragen über Tabellen – mit Transaktionen, Joins und Konsistenzgarantien
- Vektordatenbank: semantische Ähnlichkeitssuche über Embeddings – “finde Inhalte, die inhaltlich zu dieser Anfrage passen”
Was SQL-Datenbanken auszeichnet
Relationale Datenbanken organisieren Daten in Tabellen mit festem Schema und beantworten exakte Fragen: Welche Bestellungen hat Kundin X im März aufgegeben? Wie hoch war der Umsatz pro Region?
Stärken:
- ACID-Transaktionen: Entweder eine Buchung geht komplett durch oder gar nicht
- Joins und Aggregationen: Daten aus mehreren Tabellen kombinieren
- Exakte Ergebnisse: deterministische Antworten, keine Näherungen
- Jahrzehnte an Tooling, Know-how und Betriebserfahrung
Technisch stützen sich SQL-Datenbanken auf B-Trees und verwandte Index-Strukturen: perfekt für exakte Lookups, Bereichsabfragen und Sortierung.
Die Grenze: Bedeutung. Eine SQL-Datenbank findet WHERE titel = 'Kündigungsfrist' – aber nicht das Dokument, in dem stattdessen “Vertragslaufzeit und Beendigung” steht. Volltextsuche hilft bei Wortformen, versteht aber keine Semantik.
Was Vektordatenbanken auszeichnet
Vektordatenbanken speichern Embeddings – hochdimensionale Zahlenvektoren, die die Bedeutung von Texten, Bildern oder Audio repräsentieren. Ähnliche Inhalte liegen im Vektorraum nah beieinander. Die zentrale Operation ist die Nearest-Neighbor-Suche: Zu einem Anfrage-Vektor werden die semantisch nächsten Einträge gefunden.
Stärken:
- Semantische Suche: findet Ähnliches trotz komplett anderer Wortwahl
- Grundlage für RAG: relevante Chunks für den LLM-Kontext abrufen
- Skaliert auf Millionen Vektoren mit Millisekunden-Latenz
- Metadaten-Filter kombinierbar mit Ähnlichkeitssuche
Möglich machen das ANN-Indizes (Approximate Nearest Neighbor) wie HNSW: Sie finden nicht garantiert die exakt nächsten Nachbarn, aber sehr wahrscheinlich – und dafür um Größenordnungen schneller als ein vollständiger Vergleich.
Die Grenzen: Keine Transaktionen im klassischen Sinn, keine Joins, keine referenzielle Integrität. Eine Vektordatenbank ist ein Suchindex, kein System of Record.
Wann was?
SQL-Datenbank, wenn:
- Daten strukturiert sind und exakte Antworten gefragt sind
- Konsistenz kritisch ist (Zahlungen, Bestände, Nutzerkonten)
- Du Reporting, Aggregationen und Joins brauchst
Vektordatenbank, wenn:
- Nutzer in natürlicher Sprache suchen sollen
- Du eine RAG-Pipeline baust und Chunks per Ähnlichkeit abrufst
- Du Empfehlungen, Duplikat-Erkennung oder Clustering auf unstrukturierten Daten brauchst
In fast jedem realen System: beides. Die SQL-Datenbank bleibt die Quelle der Wahrheit für strukturierte Daten; die Vektordatenbank indexiert die unstrukturierten Inhalte für die semantische Suche.
Typische Architektur in RAG-Projekten
Wie das Zusammenspiel konkret aussieht, zeigt eine typische RAG-Architektur:
- SQL-Datenbank hält die Stammdaten: Dokumente mit Titel, Autor, Berechtigungen, Versionsständen
- Embedding-Pipeline zerlegt die Dokumente per Chunking und schreibt die Vektoren in den Vektorindex – zusammen mit einer Referenz auf den SQL-Datensatz
- Zur Laufzeit liefert die Vektorsuche die semantisch passenden Chunks, während SQL-Filter Berechtigungen und Metadaten prüfen
- Das LLM bekommt die gefilterten Chunks als Kontext und generiert die Antwort
Wichtig dabei: Die Vektordatenbank hält nie die einzige Kopie der Daten. Geht der Index verloren oder wechselst du das Embedding-Modell, wird er aus der SQL-Quelle einfach neu aufgebaut. Diese klare Rollenverteilung – SQL als System of Record, Vektorindex als abgeleitete Suchstruktur – erspart viele Konsistenzprobleme.
Der Hybrid-Weg: Vektoren in der SQL-Datenbank
Die Grenze verschwimmt zunehmend: Viele relationale Datenbanken haben inzwischen Vektor-Erweiterungen – am bekanntesten ist pgvector für PostgreSQL. Damit lassen sich Embeddings als Spaltentyp speichern und per ANN-Index durchsuchen, direkt neben den relationalen Daten.
Vorteile des Hybrid-Ansatzes:
- Ein System weniger zu betreiben, sichern und überwachen
- Vektorsuche und relationale Filter in einer Abfrage (inklusive Joins)
- Transaktionale Konsistenz zwischen Daten und ihren Embeddings
Wann eine dedizierte Vektordatenbank trotzdem sinnvoll ist:
- Sehr große Vektormengen oder sehr hohe Query-Raten
- Spezielle Anforderungen an Index-Tuning, Sharding oder Multi-Tenancy
- Die Vektor-Workload würde die operative Datenbank ausbremsen
Entscheidungsbaum
Sind deine Daten strukturiert und brauchst du exakte Abfragen?
├── Ja → SQL-Datenbank (wie bisher)
└── Brauchst du semantische Suche über unstrukturierte Inhalte?
├── Nein → SQL reicht
└── Ja
└── Betreibst du bereits PostgreSQL und ist die Vektormenge moderat?
├── Ja → pgvector (Hybrid in einer Datenbank)
└── Nein → Dedizierte Vektordatenbank neben der SQL-DBFaustregel: Starte mit dem, was du hast. Wer schon PostgreSQL betreibt, kommt mit pgvector oft erstaunlich weit – eine dedizierte Vektordatenbank ist eine Skalierungs-Entscheidung, kein Pflicht-Startpunkt. Und die SQL-Datenbank bleibt in jedem Szenario an Bord: Die Frage lautet nie “SQL oder Vektor”, sondern “Vektor zusätzlich – und wenn ja, wo?”.