Datenbank-Paradigmen · Grundlagen & Praxis

Tabelle, Vektor, Graph: Drei Datenbank-Welten im Architektur-Vergleich

Relationale Datenbanken beherrschen die IT seit fünf Jahrzehnten. Doch mit KI-Embeddings und hochvernetzten Datenmodellen stoßen sie an konzeptionelle Grenzen. Vektor- und Graph-Datenbanken versprechen Abhilfe – aber für fundamental unterschiedliche Probleme. Wir analysieren Funktionsprinzipien, praxisrelevante Einsatzszenarien und die wichtigsten Open-Source-Akteure.

Von der Redaktion  ·  Lesedauer ca. 18 Minuten  ·  Stand: März 2026

Wer heute eine neue Anwendung plant, steht vor einer Grundsatzfrage, die noch vor zehn Jahren trivial erschien: Welche Datenbank passt zum Problem? Die Antwort „nimm PostgreSQL“ ist nicht falsch – aber sie ist nicht mehr automatisch vollständig. Zwei Klassen spezialisierter Systeme haben sich neben dem relationalen Modell fest etabliert: Vektor-Datenbanken, angetrieben durch den KI-Boom, und Graph-Datenbanken, getrieben durch die Erkenntnis, dass manche Daten erst durch ihre Beziehungen wertvoll werden.

Dieser Artikel vergleicht die drei Paradigmen nicht als Konkurrenten, sondern als komplementäre Werkzeuge. Denn wie bei Programmiersprachen gilt: Wer nur einen Hammer kennt, für den sieht alles aus wie ein Nagel. Und wer eine Graphen-Traversierung in SQL nachbaut, hat spätestens beim fünften rekursiven JOIN die Kontrolle über die Laufzeit verloren.

1 Relationale Datenbanken – Das bewährte Fundament

Funktionsprinzip

Das relationale Modell, 1970 von Edgar F. Codd bei IBM formalisiert, organisiert Daten in zweidimensionalen Tabellen (Relationen). Jede Zeile (Tupel) repräsentiert einen Datensatz, jede Spalte (Attribut) eine Eigenschaft. Beziehungen zwischen Tabellen entstehen über Fremdschlüssel – Verweise, die referenzielle Integrität garantieren. Die Abfragesprache SQL ermöglicht deklarative Datenmanipulation: Der Nutzer beschreibt, was er haben möchte, nicht wie die Maschine es beschaffen soll.

Zentral ist das ACID-Paradigma: Atomicity, Consistency, Isolation und Durability gewährleisten, dass Transaktionen entweder vollständig oder gar nicht durchgeführt werden – eine Eigenschaft, ohne die Bankensoftware, ERP-Systeme und jede Form von Finanzbuchhaltung undenkbar wäre. Der Query-Optimizer übersetzt deklarative SQL-Statements in effiziente Ausführungspläne und wählt dabei automatisch zwischen Index-Scans, Hash-Joins und sequentiellen Zugriffen.

Einsatzzwecke

Überall dort, wo strukturierte Daten mit definierten Beziehungen verarbeitet werden und Transaktionssicherheit nicht verhandelbar ist, bleiben relationale Systeme die erste Wahl. Das Spektrum reicht von klassischen OLTP-Workloads (Online Transaction Processing) – E-Commerce-Bestellungen, Kontoführungssysteme, Warenwirtschaft – bis hin zu analytischen Szenarien (OLAP), bei denen moderne relationale Engines wie PostgreSQL mit Partitionierung, Parallelisierung und materialized Views beeindruckende Leistung zeigen.

Für regulierte Branchen wie Finanzdienstleistungen oder Gesundheitswesen sind ACID-Garantien nicht optional, sondern aufsichtsrechtlich gefordert. Die Nachvollziehbarkeit jeder Transaktion – vom Buchungssatz bis zum Audit-Trail – macht relationale Datenbanken hier zum unverzichtbaren Rückgrat.

Open-Source-Marktführer

-- Klassisches SQL: Kunden mit ihren Bestellungen
SELECT k.name, k.email, 
       COUNT(b.id) AS anzahl_bestellungen,
       SUM(b.betrag) AS gesamtumsatz
FROM kunden k
JOIN bestellungen b ON k.id = b.kunden_id
WHERE b.datum >= '2025-01-01'
GROUP BY k.id, k.name, k.email
HAVING SUM(b.betrag) > 1000
ORDER BY gesamtumsatz DESC;

2 Vektor-Datenbanken – Das Gedächtnis der KI

Funktionsprinzip

Vektor-Datenbanken speichern Daten als hochdimensionale numerische Vektoren – typischerweise sogenannte Embeddings, die von neuronalen Netzen erzeugt werden. Ein Embedding ist die mathematische Repräsentation eines Objekts (Text, Bild, Audio) in einem Vektorraum, wobei semantisch ähnliche Objekte nahe beieinander liegen. Das Herzstück ist die Approximate Nearest Neighbor Search (ANN): Statt exakte Ergebnisse in astronomischen Dimensionen zu berechnen, nutzen ANN-Algorithmen wie HNSW (Hierarchical Navigable Small World) oder IVF (Inverted File Index) Approximationen, die Geschwindigkeit um Größenordnungen steigern – bei geringfügigem Genauigkeitsverlust.

Die Distanzmetriken bestimmen, wie „Nähe“ definiert wird: Kosinus-Ähnlichkeit misst den Winkel zwischen Vektoren (ideal für Textvergleiche), euklidische Distanz den geometrischen Abstand, und das Skalarprodukt kombiniert Richtung mit Magnitude. Die Wahl der Metrik hängt direkt vom verwendeten Embedding-Modell ab – ein häufig unterschätzter Konfigurationsaspekt.

Einsatzzwecke

Der primäre Treiber ist Retrieval-Augmented Generation (RAG): Unternehmenswissen – interne Dokumente, Policies, Verträge – wird in Embeddings umgewandelt und in einer Vektor-DB indexiert. Bei einer Nutzeranfrage sucht das System die semantisch relevantesten Textpassagen und übergibt sie als Kontext an ein Large Language Model. Das reduziert Halluzinationen und macht KI-Antworten nachvollziehbar.

Darüber hinaus treiben Vektor-Datenbanken visuelle Suchen (Reverse Image Search), Anomalie-Erkennung in Sensordaten, Plagiatsprüfung und personalisierte Empfehlungssysteme an. Im Compliance-Umfeld ermöglichen sie die semantische Suche über regulatorische Texte: „Finde alle Vorschriften, die inhaltlich dem neuen AMLR-Artikel 74 entsprechen“ – eine Aufgabe, an der Volltextsuche zuverlässig scheitert.

Open-Source-Marktführer

# Python: Semantische Suche mit Qdrant
from qdrant_client import QdrantClient, models

client = QdrantClient("localhost", port=6333)

# Ähnlichkeitssuche: finde die 5 nächsten Nachbarn
results = client.query_points(
    collection_name="compliance_docs",
    query=query_embedding,  # 1536-dim Vektor
    query_filter=models.Filter(
        must=[models.FieldCondition(
            key="doc_type",
            match=models.MatchValue(value="regulation")
        )]
    ),
    limit=5
)

3 Graph-Datenbanken – Beziehungen als First-Class Citizens

Funktionsprinzip

Graph-Datenbanken modellieren Daten als Netzwerk aus Knoten (Nodes) und Kanten (Edges). Knoten repräsentieren Entitäten – Personen, Firmen, Konten, IP-Adressen –, Kanten die Beziehungen zwischen ihnen. Beide können beliebige Eigenschaften (Properties) tragen. Der entscheidende Unterschied zum relationalen Modell: Beziehungen sind keine nachträglichen Verknüpfungen über Fremdschlüssel, sondern physisch gespeicherte, eigenständige Datenstrukturen.

Diese Architektur ermöglicht Index-freie Adjazenz: Jeder Knoten enthält direkte Pointer zu seinen Nachbarn. Eine Traversierung – „folge allen KENNT-Kanten ausgehend von Person X über drei Stufen“ – benötigt keine teuren JOIN-Operationen, sondern springt in konstanter Zeit von Knoten zu Knoten. Bei hochvernetzten Daten (Social Networks, Finanztransaktions-Graphen, Wissensgraphen) ergibt sich ein Performancevorteil von mehreren Größenordnungen gegenüber rekursiven SQL-Abfragen.

Einsatzzwecke

Graph-Datenbanken entfalten ihre Stärke, wo das Muster der Verbindungen die eigentliche Information trägt. In der Geldwäsche-Erkennung (AML) erkennen sie Transaktionsketten über verschachtelte Firmenkonstrukte – sogenannte Layering-Strukturen –, die in tabellarischer Darstellung unsichtbar bleiben. Im Fraud Detection decken sie Ringe koordinierter Konten auf; im Identity Resolution verschmelzen sie fragmentierte Datensätze zu einem einheitlichen Kundenbild.

Weitere Domänen umfassen Wissensgraphen (Knowledge Graphs) für Enterprise Search, Abhängigkeitsanalysen in IT-Infrastrukturen (Impact Analysis), Empfehlungssysteme basierend auf Nutzungsmustern (Netflix, Amazon), Netzwerk- und Telecom-Topologien sowie Life-Sciences-Anwendungen (Protein-Interaktionen, Drug Discovery). Im Compliance-Kontext modellieren sie UBO-Ketten (Ultimate Beneficial Ownership) und ermöglichen die automatisierte Prüfung, ob wirtschaftlich Berechtigte über mehr als vier Beteiligungsstufen hinweg korrekt identifiziert wurden.

Open-Source-Marktführer

// Cypher (Neo4j): Verdächtige Transaktionsketten finden
MATCH pfad = (quelle:Konto)-[:UEBERWEISUNG*2..5]->(ziel:Konto)
WHERE quelle.risiko_score > 0.7
  AND ziel.land IN ['KY', 'PA', 'VG']
  AND ALL(tx IN relationships(pfad) 
         WHERE tx.betrag < 14999)  // Structuring-Indikator
RETURN pfad, 
       reduce(s = 0, tx IN relationships(pfad) | s + tx.betrag) 
         AS gesamtvolumen
ORDER BY gesamtvolumen DESC
LIMIT 20

Drei Paradigmen im Direktvergleich

Entscheidungshilfe: Wann welche Datenbank?

Die Wahl des Datenbank-Paradigmas ist keine Geschmacksfrage, sondern eine architektonische Entscheidung, die sich an der Natur des Problems orientiert. Die folgende Heuristik hat sich in der Praxis bewährt:

„Wenn die Entitäten im Mittelpunkt stehen, nimm SQL. Wenn die Bedeutung zählt, nimm Vektoren. Wenn die Beziehungen die Information sind, nimm einen Graphen.“

In der Realität kombinieren moderne Architekturen häufig mehrere Paradigmen: PostgreSQL als System of Record, Qdrant für die semantische Suche im RAG-Pipeline und Neo4j für die Netzwerkanalyse im Fraud-Detection-Modul. Der Polyglot Persistence-Ansatz ist kein Overengineering, sondern die logische Konsequenz aus der Erkenntnis, dass ein einzelnes Datenmodell nicht alle Zugriffsmuster optimal bedienen kann.

Architektur-Diagramme

Die folgenden drei Mermaid-Diagramme visualisieren die Kernkonzepte der einzelnen Paradigmen sowie die Entscheidungslogik für die DB-Wahl. Sie können direkt in WordPress gerendert werden (Plugin: WP Mermaid oder via <script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js">).

graph LR
    subgraph REL["🗃️ Relational"]
        direction TB
        T1["Tabelle: Kunden"]
        T2["Tabelle: Bestellungen"]
        T3["Tabelle: Produkte"]
        T1 -->|"FK: kunden_id"| T2
        T2 -->|"FK: produkt_id"| T3
    end

    subgraph VEC["🧮 Vektor"]
        direction TB
        V1["Vektor [0.12, -0.87, ..., 0.45]"]
        V2["Vektor [0.11, -0.85, ..., 0.44]"]
        V3["Vektor [-0.73, 0.21, ..., 0.88]"]
        V1 -.-|"Kosinus: 0.97"| V2
        V1 -.-|"Kosinus: 0.23"| V3
    end

    subgraph GRA["🔗 Graph"]
        direction TB
        N1(("Alice"))
        N2(("Bob"))
        N3(("Firma X"))
        N1 -->|"KENNT"| N2
        N1 -->|"ARBEITET_BEI"| N3
        N2 -->|"ARBEITET_BEI"| N3
    end

    style REL fill:#e8f4fd,stroke:#2196F3,stroke-width:2px
    style VEC fill:#fff3e0,stroke:#FF9800,stroke-width:2px
    style GRA fill:#e8f5e9,stroke:#4CAF50,stroke-width:2px

flowchart TD
    START["Neue Anwendung: Datenbank wählen"] --> Q1{"Sind die Daten
hochstrukturiert
mit festen Schemata?"}
    Q1 -->|"Ja"| Q2{"Benötigen Sie
ACID-Transaktionen?"}
    Q1 -->|"Nein"| Q3{"Geht es um semantische
Ähnlichkeit / KI-Embeddings?"}

    Q2 -->|"Ja"| RDB["✅ Relationale DB
PostgreSQL, MySQL"]
    Q2 -->|"Nein, eher Analytik"| RDB2["✅ Relationale DB / Data Warehouse
PostgreSQL + Citus, DuckDB"]

    Q3 -->|"Ja"| Q4{"Datenvolumen > 1 Mio.
Vektoren?"}
    Q3 -->|"Nein"| Q5{"Stehen Beziehungen
zwischen Entitäten
im Mittelpunkt?"}

    Q4 -->|"Ja"| VDB["✅ Dedizierte Vektor-DB
Milvus, Qdrant, Weaviate"]
    Q4 -->|"Nein"| VDB2["✅ pgvector-Extension
PostgreSQL + pgvector"]

    Q5 -->|"Ja"| Q6{"Brauchen Sie Graph-
Algorithmen (PageRank,
Community Detection)?"}
    Q5 -->|"Nein"| DOC["✅ Dokument-DB / Key-Value
MongoDB, Redis"]

    Q6 -->|"Ja"| GDB["✅ Graph-DB
Neo4j, JanusGraph"]
    Q6 -->|"Nein, nur Beziehungsabfragen"| GDB2["✅ Multi-Model-DB
ArangoDB, Apache AGE"]

    style RDB fill:#e8f4fd,stroke:#1976D2,color:#000
    style RDB2 fill:#e8f4fd,stroke:#1976D2,color:#000
    style VDB fill:#fff3e0,stroke:#E65100,color:#000
    style VDB2 fill:#fff3e0,stroke:#E65100,color:#000
    style GDB fill:#e8f5e9,stroke:#2E7D32,color:#000
    style GDB2 fill:#e8f5e9,stroke:#2E7D32,color:#000
    style DOC fill:#f3e5f5,stroke:#7B1FA2,color:#000

flowchart LR
    APP["🖥️ Anwendung"] --> API["API Gateway"]

    API --> PG["PostgreSQL
System of Record
ACID-Transaktionen"]
    API --> QD["Qdrant
Vektor-Index
Semantische Suche"]
    API --> NEO["Neo4j
Graph-Engine
Netzwerk-Analyse"]

    PG -->|"CDC via Debezium"| KAFKA["Apache Kafka
Event Stream"]
    KAFKA -->|"Embedding-Pipeline"| QD
    KAFKA -->|"Graph-ETL"| NEO

    QD -->|"Top-k Ergebnisse"| RAG["🤖 RAG-Pipeline
LLM + Kontext"]
    NEO -->|"Pfad-Analyse"| ALERT["🚨 Alert-Engine
Fraud / AML"]
    PG -->|"Reports"| BI["📊 BI / Reporting"]

    style PG fill:#e8f4fd,stroke:#1976D2,stroke-width:2px
    style QD fill:#fff3e0,stroke:#E65100,stroke-width:2px
    style NEO fill:#e8f5e9,stroke:#2E7D32,stroke-width:2px
    style KAFKA fill:#ffebee,stroke:#c62828,stroke-width:2px
    style RAG fill:#f3e5f5,stroke:#7B1FA2,stroke-width:2px
    style ALERT fill:#fce4ec,stroke:#c62828,stroke-width:2px

Bild-Prompts für ausführliche Architektur-Diagramme

Die folgenden vier Prompts sind für die Generierung detaillierter technischer Illustrationen optimiert (z. B. mit Midjourney, DALL-E 3, Ideogram oder Diagramm-Tools wie Excalidraw/draw.io). Sie beschreiben jeweils ein Schlüsselkonzept des Artikels als visuelle Komposition.

Fazit: Es gibt keine Silver-Bullet-Datenbank

Die Ära der monokulturellen Datenbank-Landschaft ist vorbei. Relationale Systeme bleiben das unverzichtbare Fundament für alles, was Transaktionssicherheit und strukturierte Abfragen erfordert – und PostgreSQL zeigt mit Extensions wie pgvector und Apache AGE, dass es sich in die Domänen der Spezialisten hinein dehnen kann. Für ernsthafte KI-Workloads mit Millionen von Embeddings führt an dedizierten Vektor-Datenbanken kein Weg vorbei. Und wo immer das Muster der Verbindungen die eigentliche Erkenntnis liefert – in der Geldwäsche-Erkennung, in der Netzwerkforensik, im Wissensmanagement –, sind Graph-Datenbanken nicht nur eine Option, sondern eine Notwendigkeit.

Die kluge Architekturentscheidung liegt nicht in der Wahl einer Datenbank, sondern im Verständnis, welches Datenmodell welches Problem am natürlichsten abbildet. Polyglot Persistence ist kein Buzzword, sondern der pragmatische Ausdruck dieser Einsicht. Wer das beherrscht, baut Systeme, die nicht nur heute funktionieren, sondern auch morgen noch skalieren – egal, welche Anforderung als nächstes um die Ecke kommt.