Datenbanktypen: Relational, Spaltenorientiert, Dokument, Graph & mehr

Was „Datenbanktypen" wirklich bedeutet

Ein „Datenbanktyp" ist nicht nur ein Etikett — er fasst zusammen, wie ein System Daten speichert, wie du es abfragst und wofür es optimiert ist. Diese Wahl beeinflusst direkt die Geschwindigkeit (was schnell vs. langsam ist), die Kosten (Hardware- oder Cloud-Ausgaben) und die Fähigkeiten (Transaktionen, Analytics, Suche, Replikation und mehr).

Warum der „Typ" wichtig ist

Verschiedene Datenbanktypen machen unterschiedliche Kompromisse:

• Eine relationale Datenbank ist großartig, wenn deine Daten strukturiert sind und du verlässliche Transaktionen brauchst.
• Eine spaltenorientierte Datenbank glänzt, wenn du viele Zeilen scannst, um analytische Fragen zu beantworten.
• Eine Dokumentdatenbank kann schneller vorankommen, wenn sich die Form deiner Anwendungsdaten oft ändert.
• Eine Graphdatenbank ist für beziehungsstarke Daten gebaut.
• Eine Vektor-Datenbank konzentriert sich auf „Ähnlichkeit" statt exakter Übereinstimmung.

Diese Designentscheidungen beeinflussen:

• Abfragemuster: viele kleine Lookups, komplexe Joins oder große analytische Scans?
• Skalierungsmodell: auf eine große Maschine skalieren oder über viele Maschinen skalieren?
• Datenmodell: Tabellen, Dokumente, Key-Value-Paare, Graphen, Vektoren oder zeitgestempelte Punkte.

Was du in diesem Leitfaden lernst

Dieser Artikel führt durch die wichtigsten Datenbanktypen und erklärt für jeden:

• Worin er am besten ist (und wo er Schwächen hat)
• Typische Anwendungsfälle in echten Produkten
• Wichtige Tradeoffs, die Performance, Kosten und Komplexität beeinflussen

Ein kurzer Hinweis zu „Multi-Model"-Systemen

Viele moderne Produkte verwischen die Grenzen. Manche relationale Datenbanken fügen JSON-Unterstützung hinzu, die mit einer Dokumentdatenbank überlappt. Manche Such- und Analytics-Plattformen bieten Vektor-Indizierung wie eine Vektor-Datenbank. Andere kombinieren Streaming und Speicherung mit Time-Series-Funktionen.

„Typ" ist also kein strenges Kästchen — er ist nützlich, um Standardstärken und die Arten von Workloads zu verstehen, die eine Datenbank am besten handhabt.

Wie du diesen Leitfaden zur Shortlist-Narrowing nutzt

Fange mit deinem Haupt-Workload an:

• Wenn du strukturierte Daten und Transaktionen brauchst, starte mit einer relationalen Datenbank.
• Wenn du schwere Reports und Dashboards machst, sieh dir eine spaltenorientierte Datenbank oder ein Warehouse an.
• Wenn sich die Form der App-Daten oft ändert, erwäge eine Dokumentdatenbank.
• Wenn du extrem schnelle Lookups per Key brauchst, ist ein Key-Value-Store ein starker Kandidat.

Verwende dann den Abschnitt „Wie man den richtigen Datenbanktyp wählt", um basierend auf Skalierung, Konsistenzanforderungen und den Abfragen, die du am häufigsten ausführen wirst, weiter einzugrenzen.

Relationale Datenbanken (SQL): Der Default für strukturierte Daten

Relationale Datenbanken sind das, was viele sich vorstellen, wenn sie „Datenbank" hören. Daten sind in Tabellen organisiert, bestehend aus Zeilen (Records) und Spalten (Felder). Ein Schema definiert, wie jede Tabelle aussieht — welche Spalten existieren, welche Typen sie haben und wie Tabellen zueinander in Beziehung stehen.

Warum SQL überall ist

Relationale Systeme werden typischerweise mit SQL (Structured Query Language) abgefragt. SQL ist beliebt, weil es lesbar und ausdrucksstark ist:

• Du kannst filtern und sortieren (WHERE, ORDER BY).
• Daten über Tabellen hinweg kombinieren (JOIN).
• Ergebnisse zusammenfassen (GROUP BY).

Die meisten Reporting-Tools, Analytics-Plattformen und Business-Apps sprechen SQL, was es zu einer sicheren Default-Wahl macht, wenn du breite Kompatibilität brauchst.

ACID-Transaktionen, einfach erklärt

Relationale Datenbanken sind bekannt für ACID-Transaktionen, die helfen, Daten korrekt zu halten:

• Atomicity: eine mehrstufige Änderung ist „alles oder nichts".
• Consistency: Regeln (wie Foreign Keys) bleiben nach Änderungen gültig.
• Isolation: gleichzeitige Updates korruptieren sich nicht gegenseitig.
• Durability: einmal persistierte Daten überstehen Abstürze.

Das ist wichtig, wenn Fehler teuer sind — etwa doppelte Abbuchungen oder verlorene Lagerbestandsupdates.

Best-fit Workloads

Eine relationale Datenbank passt in der Regel für strukturierte, gut definierte Daten und Workflows wie:

• Business-Anwendungen (CRM/ERP-ähnliche Systeme)
• Finanzen, Zahlungen, Abrechnung
• Inventar, Bestellungen, Reservierungen

Häufige Fallstricke

Die gleiche Struktur, die relationale Datenbanken zuverlässig macht, kann Reibung erzeugen:

• Starre Schemata: häufige Änderungen an der Datenstruktur können Migrationen erfordern.
• Join-lastige Skalierung: viele Joins über große Tabellen können langsam oder teuer werden, besonders bei Verteilung über viele Maschinen.

Wenn dein Datenmodell sich ständig ändert — oder du extreme horizontale Skalierung mit einfachen Zugriffsmustern brauchst — können andere Datenbanktypen besser passen.

Spaltenorientierte Datenbanken: Für Analytics gebaut

Spaltenorientierte Datenbanken speichern Daten „pro Spalte" statt „pro Zeile". Diese Änderung hat großen Einfluss auf Geschwindigkeit und Kosten für Analytics-Workloads.

Row-Store vs. Column-Store

In einem traditionellen Row-Store (üblich in relationalen DBs) liegen alle Werte eines Records zusammen. Das ist großartig, wenn du häufig einen Kunden/eine Bestellung einzeln liest oder aktualisierst.

In einem Column-Store liegen alle Werte für dasselbe Feld zusammen — jede price, jedes country, jeder timestamp. Das macht es effizient, nur die wenigen Spalten zu lesen, die ein Report benötigt, ohne ganze Zeilen von der Festplatte zu holen.

Warum Columnar für Reporting schnell ist

Analytics- und BI-Abfragen:

• Scannen oft viele Datensätze
• Wählen eine kleine Menge an Spalten
• Berechnen Aggregationen wie SUM, AVG, COUNT und gruppieren nach Dimensionen

Columnar Storage beschleunigt diese Muster, weil weniger Daten gelesen werden und sich starke Kompression ergibt (ähnliche Werte komprimieren gut). Viele Columnar-Engines nutzen außerdem vektorisierte Ausführung und intelligente Indizierung/Partitionierung, um große Scans zu beschleunigen.

Typische Abfragemuster

Spaltenorientierte Systeme glänzen bei Dashboards und Reporting: „Umsatz pro Woche", „Top 20 Produkte pro Region", „Conversion-Rate nach Channel" oder „Fehler pro Service in den letzten 30 Tagen". Diese Abfragen berühren viele Zeilen, aber vergleichsweise wenige Spalten.

Tradeoffs: OLTP-Updates und Point-Lookups

Wenn dein Workload hauptsächlich „hole einen Datensatz per ID" oder „aktualisiere eine einzelne Zeile Dutzende Male pro Sekunde" ist, kann Columnar langsamer oder teurer wirken. Schreibzugriffe sind oft für Batches (append-heavy Ingestion) optimiert statt für viele kleine Updates.

Wo es glänzt

Spaltenorientierte Datenbanken sind stark für:

• BI und Executive Dashboards
• Event- und Clickstream-Analytics
• Großskaliges Reporting auf Logs oder Transaktionen

Wenn schnelle Aggregationen über viel Daten Priorität haben, ist Columnar meist der erste Typ, den man evaluiert.

Dokumentdatenbanken: Flexible Schemata für App-Daten

Dokumentdatenbanken speichern Daten als „Dokumente" — eigenständige Datensätze, die stark an JSON erinnern. Anstatt Informationen auf viele Tabellen zu verteilen, behält man typischerweise zusammengehörige Felder in einem Objekt (inkl. verschachtelter Arrays und Unterobjekte). Das macht sie zur natürlichen Wahl für Anwendungsdaten.

Das Dokumentenmodell (JSON-ähnliche Records)

Ein Dokument kann einen Benutzer, ein Produkt oder einen Artikel repräsentieren — komplett mit Attributen, die von einem Dokument zum nächsten unterschiedlich sein können. Ein Produkt kann size und color haben, ein anderes dimensions und materials, ohne ein einheitliches Schema für alle Records zu erzwingen.

Diese Flexibilität ist besonders hilfreich, wenn sich Anforderungen häufig ändern oder unterschiedliche Items verschiedene Feldmengen haben.

Indizierung, grob erklärt

Um nicht jedes Dokument scannen zu müssen, nutzen Dokumentdatenbanken Indizes — Datenstrukturen, die helfen, passende Dokumente schnell zu finden. Du kannst häufige Lookup-Felder indizieren (z. B. email, sku, status) und viele Systeme indizieren auch verschachtelte Felder (z. B. address.city). Indizes beschleunigen Lesezugriffe, erhöhen aber die Schreibkosten, da der Index bei Änderungen aktualisiert werden muss.

Stärken — und Tradeoffs

Dokumentdatenbanken glänzen bei sich entwickelnden Schemata, verschachtelten Daten und API-freundlichen Payloads. Die Tradeoffs zeigen sich oft bei:

• Komplexen Joins über viele Entitäten (weniger natürlich als in einer relationalen DB)
• Multi-Document-Transaktionen bei hoher Skalierung (in vielen Produkten unterstützt, kann aber Performance kosten)
• Strikter Normalisierung (Teams duplizieren manchmal Daten, um Lesezugriffe zu vereinfachen, was sorgfältige Update-Logik erfordert)

Häufige Anwendungsfälle

Sie sind eine starke Wahl für Content-Management, Produktkataloge, Benutzerprofile und Backend-APIs — überall dort, wo deine Daten gut zu „ein Objekt pro Seite/Screen/Request" passen.

Key-Value-Stores: Einfach und sehr schnelle Lookups

Key-Value-Stores sind das einfachste Datenbankmodell: du speicherst einen Wert (alles von einem String bis zu einem JSON-BLOB) und holst ihn mit einem einzigartigen Schlüssel ab. Die Kernoperation ist quasi „gib mir den Wert für diesen Key", weshalb diese Systeme extrem schnell sein können.

Das Key-Value-Modell (und warum es schnell ist)

Da Lese- und Schreiboperationen um einen einzelnen Primärschlüssel zentriert sind, können Key-Value-Stores für geringe Latenz und hohen Durchsatz optimiert werden. Viele sind so konzipiert, heiße Daten im Speicher zu halten, komplexe Query-Planung zu minimieren und horizontal zu skalieren.

Dieses einfache Modell prägt auch, wie du Daten modellierst: statt die DB zu fragen „finde alle Nutzer in Berlin, die sich letzte Woche angemeldet haben", designst du meist Keys, die direkt auf den gewünschten Datensatz zeigen (z. B. user:1234:profile).

Warum es beliebt für Caching und Sessions ist

Key-Value-Stores werden oft als Cache vor einer langsameren Primärdatenbank eingesetzt (z. B. einer relationalen DB). Wenn deine App dieselben Daten wiederholt braucht — Produktdetails, Nutzerberechtigungen, Preisregeln — vermeidet das Caching durch Key das erneute Berechnen oder Abfragen.

Sie eignen sich auch natürlich für Session-Speicherung (z. B. session:<id> -> session data), weil Sessions häufig gelesen und aktualisiert werden und automatisch ablaufen können.

TTL, Eviction und Speicher vs. Disk

Die meisten Key-Value-Stores unterstützen eine TTL (Time to Live), sodass Daten ohne manuelle Aufräumarbeit verfallen — ideal für Sessions, Einmal-Tokens und Rate-Limit-Counter.

Wenn Speicher begrenzt ist, nutzen Systeme häufig Eviction-Policies (z. B. LRU) zum Entfernen alter Einträge. Einige Produkte sind memory-first, andere können Daten auf Disk persistieren. Die Wahl zwischen Speicher und Disk hängt davon ab, ob du für Geschwindigkeit (Speicher) oder Haltbarkeit/Wiederherstellung (Disk/Persistenz) optimierst.

Tradeoffs, die du kennen solltest

Key-Value-Stores sind stark, wenn du den Key bereits kennst. Sie sind weniger geeignet für offene Fragestellungen.

Viele bieten eingeschränktere Abfragemuster im Vergleich zu SQL-Datenbanken. Die Unterstützung für sekundäre Indizes (Abfragen nach Feldern im Wert) variiert: manche bieten sie, manche teilweise, andere empfehlen, eigene Lookup-Keys zu pflegen.

Häufige Anwendungsfälle

Key-Value-Stores passen gut für:

• Rate Limiting: Zähler pro Nutzer/IP mit TTL-Fenster
• Feature Flags: schnelle Lesezugriffe zur Entscheidungsfindung pro Nutzer/Kohorte
• Warenkörbe: schnelle Updates eines Warenkorb-Objekts per Nutzer/Session

Wenn dein Zugriffsmuster „fetch/update per ID" ist und Latenz wichtig ist, ist ein Key-Value-Store oft der einfachste Weg, verlässliche Geschwindigkeit zu erreichen.

Wide-Column-Datenbanken: Scale-Out für operationale Speicherung

Wide-Column-Datenbanken (auch wide-column stores genannt) organisieren Daten in Column Families. Anstatt in einer festen Tabelle mit denselben Spalten für jede Zeile zu denken, gruppierst du verwandte Spalten zusammen und kannst unterschiedliche Spalten pro Zeile innerhalb einer Familie speichern.

Wide-Column vs. spaltenorientierte Analytics

Trotz ähnlicher Namen sind sie nicht dasselbe wie eine spaltenorientierte Datenbank für Analytics.

Eine columnar database speichert jede Spalte separat, um riesige Datensätze effizient zu scannen (ideal für Reporting und Aggregationen). Eine wide-column database ist für operationale Workloads bei sehr großer Skala gebaut, bei denen du viele Datensätze schnell über viele Maschinen schreiben und lesen musst.

Wo sie glänzen

Wide-Column-Systeme sind ausgelegt für:

• Hohe Schreibdurchsätze (viele Events pro Sekunde ingestieren)
• Horizontale Skalierung (zusätzliche Knoten für mehr Traffic und Daten)
• Vorhersehbare, latenzarme Reads, wenn du nach dem richtigen Key fragst

Typisches Zugriffsmuster

Das häufigste Muster ist:

• Du kennst den Partition-Key (entscheidet, wo Daten liegen), und
• Du liest oft einen Range innerhalb dieser Partition (z. B. „alle Events für Gerät X zwischen 10:00–10:05").

Das macht sie stark für zeitgeordnete Daten und append-lastige Workloads.

Tradeoffs

Bei Wide-Column-Datenbanken ist Datenmodellierung query-driven: du entwirfst Tabellen meist um die genauen Abfragen herum, die du ausführen musst. Das kann bedeuten, Daten in unterschiedlichen Formen zu duplizieren, um verschiedene Zugriffsmuster zu unterstützen.

Sie bieten auch oft eingeschränkte Joins und weniger ad-hoc Abfragemöglichkeiten als relationale DBs. Wenn deine Anwendung auf komplexen Beziehungen und flexibler Abfragefähigkeit basiert, könntest du dich eingeschränkt fühlen.

Häufige Anwendungsfälle

Wide-Column-Datenbanken werden oft für IoT-Events, Messaging- und Activity-Streams und andere großskalige operationale Daten verwendet, bei denen schnelle Writes und vorhersehbare schlüsselbasierte Reads wichtiger sind als reichhaltige relationale Abfragen.

Graphdatenbanken: Beziehungen als erstklassige Daten

Graphdatenbanken speichern Daten so, wie viele reale Systeme funktionieren: als Dinge, die mit anderen Dingen verbunden sind. Anstatt Beziehungen in Tabellen und Join-Tabellen zu pressen, sind die Verbindungen Teil des Modells.

Das Graph-Modell: Knoten, Kanten und Properties

Ein Graph hat typischerweise:

• Knoten: die Entitäten (Personen, Konten, Geräte, Produkte)
• Kanten: die Beziehungen zwischen ihnen ("folgt", "hat bezahlt", "gehört zu", "wurde an gesendet")
• Properties: Key-Value-Attribute auf Knoten und Kanten (Timestamps, Beträge, Labels)

So lassen sich Netzwerke, Hierarchien und viele-zu-vielen-Beziehungen natürlich darstellen, ohne das Schema zu verformen.

Warum Traversals Joins schlagen können

Beziehungsintensive Abfragen erfordern in einer relationalen DB oft viele Joins. Jeder zusätzliche Join kann mit wachsendem Datenvolumen Komplexität und Kosten erzeugen.

Graphdatenbanken sind für Traversals ausgelegt — vom einen Knoten zu verbundenen Knoten wandern, dann weiter zu deren Verbindungen usw. Wenn deine Fragen oft lauten „finde verbundene Dinge innerhalb von 2–6 Schritten", können Traversals schnell und lesbar bleiben, selbst wenn das Netzwerk wächst.

Fragen, die Graphen besonders gut beantworten

Graphdatenbanken sind stark bei:

• Pfaden und Trennungsgraden (kürzester Weg, Erreichbarkeit)
• Empfehlungen („Käufer von X kauften auch Y", „Freunde von Freunden")
• Betrugsringe und Anomalien (geteilte Geräte, Adressen, Zahlungsmethoden)

Tradeoffs

Graphen erfordern oft ein Umdenken im Team: Modellierung ist anders und Querysprachen (häufig Cypher, Gremlin oder SPARQL) können neu sein. Du solltest klare Konventionen für Beziehungstypen und Richtung festlegen, um das Modell wartbar zu halten.

Wann ein relationales Modell reicht

Wenn deine Beziehungen einfach sind, Abfragen größtenteils Filtern/Aggregieren sind und ein paar Joins die „verbundenen" Teile abdecken, kann eine relationale Datenbank weiterhin die einfachste Wahl sein — besonders wenn Transaktionen und Reporting bereits gut funktionieren.

Vektor-Datenbanken: Ähnlichkeitssuche für KI-Anwendungen

Vektor-Datenbanken sind für eine bestimmte Frage optimiert: „Welche Items sind einer gegebenen Eingabe am ähnlichsten?" Statt exakte Werte abzugleichen (ID oder Keyword) vergleichen sie Embeddings — numerische Repräsentationen von Inhalten (Text, Bilder, Audio, Produkte), die KI-Modelle erzeugen. Items mit ähnlicher Bedeutung liegen in diesem mehrdimensionalen Raum nah beieinander.

Warum Vektoren semantische Suche ermöglichen

Eine normale Suche verfehlt Ergebnisse, wenn die Wortwahl abweicht („laptop sleeve" vs. „notebook case"). Mit Embeddings beruht Ähnlichkeit auf Bedeutung, sodass relevante Ergebnisse gefunden werden, auch wenn nicht dieselben Wörter verwendet werden.

Kernoperationen: Ähnlichkeit + Filter

Die Hauptoperation ist die Nearest-Neighbor-Suche: gegeben ein Query-Vektor, rufe die nächsten Vektoren ab.

In echten Anwendungen kombiniert man Ähnlichkeit oft mit Filtern, z. B.:

• Nur Dokumente eines bestimmten Kunden zeigen
• Auf eine Produktkategorie oder Sprache begrenzen
• Archivierte oder minderwertige Items ausschließen

Dieses „Filter + Similarity"-Muster macht Vektor-Suche praktikabel für reale Datensätze.

Wo Vektor-Datenbanken passen

Typische Anwendungsfälle umfassen:

• RAG (Retrieval-Augmented Generation): relevanteste Passagen vor dem Antwortbau in einem LLM abrufen
• Semantische Suche: Wissensdatenbanken, Support-Tickets oder interne Docs durchsuchen
• Empfehlungen: „Nutzer, die X gesehen/gekauft haben" basierend auf Inhalt-Ähnlichkeit

Tradeoffs

Vektor-Suche beruht auf spezialisierten Indizes. Aufbau und Aktualisierung dieser Indizes kann Zeit in Anspruch nehmen und viel Speicher nutzen. Häufig muss man zwischen höherer Recall (mehr der besten Treffer finden) und niedrigerer Latenz (schnellere Antworten) abwägen.

Kombination mit relationalen oder dokumentbasierten Stores

Vektor-Datenbanken ersetzen selten dein Hauptspeichersystem. Übliche Architektur: die „Source of Truth" (Orders, Nutzer, Dokumente) liegt in einer relationalen oder dokumentbasierten DB, Embeddings + Suchindizes liegen in der Vektor-DB — anschließend verknüpfst du die Ergebnisse zurück zur Primärdatenbank für volle Datensätze und Berechtigungen.

Time-Series-Datenbanken: Optimiert für Metriken über die Zeit

Time-Series-Datenbanken (TSDBs) sind für Daten gedacht, die kontinuierlich ankommen und immer einen Zeitstempel haben. Denk an CPU-Nutzung alle 10 Sekunden, API-Latenz für jede Anfrage, Sensorwerte jede Minute oder Aktienkurse, die sich mehrfach pro Sekunde ändern.

Wie Time-Series-Daten typischerweise aussehen

Die meisten Zeitreihen-Einträge kombinieren:

• Timestamp: wann die Messung stattfand
• Metrik/Wert: die gemessene Zahl (Latenz, Temperatur, Preis)
• Tags/Labels: Metadaten zum Filtern und Gruppieren (host=web-01, region=us-east, service=checkout)

Damit lassen sich Fragen wie „Fehlerquote nach Service anzeigen" oder „Latenz zwischen Regionen vergleichen" leicht stellen.

Performance-Features, auf die TSDBs setzen

Da das Datenvolumen schnell wachsen kann, konzentrieren sich TSDBs typischerweise auf:

• Kompression: numerische Werte effizient über lange Zeiträume speichern
• Retention-Policies: alte Daten automatisch verfallen lassen (z. B. Rohdaten 7 Tage, Aggregationen 90 Tage)
• Downsampling: Details zu Rollups zusammenfassen (pro Sekunde → pro Minute → pro Stunde)

Diese Features halten Storage- und Query-Kosten vorhersagbar, ohne ständiges manuelles Aufräumen.

Typische Abfragen

TSDBs sind stark, wenn du zeitbasierte Berechnungen brauchst, wie:

• Rolling Averages (z. B. 5-Minuten-Moving-Average)
• Perzentile (p95/p99 Latenz)
• Rate of Change (Requests/Second)
• Alerting bei Schwellenwerten oder Anomalien

Wo sie passen (und wo nicht)

Typische Use Cases: Monitoring, Observability, IoT/Sensoren und finanzielle Tick-Daten.

Der Tradeoff: TSDBs sind nicht ideal für komplexe, adhoc-beziehungsreiche Abfragen über viele Entitäten (z. B. tief verschachtelte Joins wie „Users → Teams → Permissions → Projects"). Dafür sind relationale oder Graph-Datenbanken meist besser geeignet.

Warehouses und Lakehouses: Analytics in Organisationsgröße

Ein Data Warehouse ist weniger ein einzelner DBD-Typ und mehr ein Workload + Architektur: viele Teams, die große historische Daten abfragen, um Geschäftsfragen zu beantworten (Umsatztrends, Churn, Lagerbestand-Risiken). Man kann es als Managed-Produkt kaufen, aber was es zum Warehouse macht, ist die Nutzung — zentralisiert, analytisch und geteilt.

Batch vs. Streaming Ingestion (vereinfacht)

Die meisten Warehouses akzeptieren Daten auf zwei Wegen:

• Batch Ingestion: Daten landen stündlich/täglich (z. B. nächtliche Exporte). Günstiger und einfacher, aber nicht Echtzeit.
• Streaming Ingestion: Events kommen kontinuierlich (Clicks, Payments, IoT). Du siehst frischere Zahlen, aber Pipelines und Monitoring sind wichtiger.

Warum sie schnell sind: Columnar, Partitioning, Materialized Views

Warehouses sind für Analytics optimiert mit ein paar praktischen Tricks:

• Columnar Storage liest nur benötigte Spalten (ideal für Summen/Aggregate).
• Partitioning teilt große Tabellen nach Zeit oder Region, sodass Abfragen weniger Daten scannen.
• Materialized Views speichern vorab berechnete Ergebnisse (z. B. „täglicher Umsatz pro Land") zur Beschleunigung von Dashboards.

Governance ist bei Größe Pflicht

Wenn mehrere Abteilungen dieselben Zahlen nutzen, brauchst du Access Control (wer darf was sehen), Audit Trails (wer hat Daten abgefragt/geändert) und Lineage (woher eine Metrik stammt und wie sie transformiert wurde). Das ist oft genauso wichtig wie Abfragegeschwindigkeit.

Wann ein Lakehouse Sinn macht

Ein Lakehouse verbindet Warehouse-Style-Analytics mit der Flexibilität eines Data Lakes — nützlich, wenn du einen Ort für kuratierte Tabellen und rohe Dateien (Logs, Bilder, semi-strukturierte Events) haben willst, ohne alles zu duplizieren. Sinnvoll, wenn Datenvolumen hoch ist, Formate variieren und du trotzdem SQL-freundliches Reporting benötigst.

Wichtige Tradeoffs: Konsistenz, Skalierung und Abfragemuster

Die Wahl zwischen Datenbanktypen ist weniger eine Frage des „Besten" als des Fits: Was musst du abfragen, wie schnell, und was passiert, wenn Teile des Systems ausfallen?

OLTP vs. OLAP (matching the workload)

Eine Faustregel:

• OLTP (Online Transactions): viele kleine Reads/Writes (Checkout, Logins, Order-Updates). Prioritäten: geringe Latenz, korrekte Updates, viele gleichzeitige Nutzer.
• OLAP (Analytics): weniger, dafür schwerere Abfragen, die viele Zeilen scannen (Dashboards, Trends). Prioritäten: schnelle Aggregation, columnar storage, Trennung von Compute und Storage.

Relationale DBs eignen sich oft für OLTP; Columnar-Systeme, Warehouses und Lakehouses sind häufige OLAP-Wahlen.

CAP in Klartext

Wenn ein Netzwerkpartition auftritt, kannst du typischerweise nicht alle drei gleichzeitig haben:

• Consistency: alle sehen sofort dieselben Daten.
• Availability: das System reagiert weiterhin.
• Partition Tolerance: es funktioniert trotz Netzwerkteilen.

Viele verteilte DBs bleiben während Problemen verfügbar und gleichen später ab (eventual consistency). Andere priorisieren strikte Korrektheit und lehnen Anfragen ab, bis der Zustand wieder gesund ist.

Skalierung: vertical, horizontal und Sharding

• Vertical Scaling: größere Maschine — einfach, aber begrenzt.
• Horizontal Scaling: mehr Maschinen — mehr Kapazität, mehr Koordination.
• Sharding: Aufteilen von Daten über Knoten (z. B. nach Kunden-ID). Skaliert, aber Cross-Shard-Queries und Transaktionen werden schwerer.

Transaktionen und Nebenläufigkeit

Wenn viele Nutzer dieselben Daten aktualisieren, brauchst du klare Regeln. Transaktionen bündeln Schritte zu „alles-oder-nichts". Locking und Isolation Levels verhindern Konflikte, können aber Durchsatz reduzieren; lockerere Isolation erhöht die Geschwindigkeit, kann aber Anomalien erlauben.

Operative Aspekte (überspringe diese nicht)

Plane früh für Backups, Replikation und Disaster Recovery. Überlege auch, wie leicht sich Restores testen lassen, Lags überwachen und Upgrades durchführen — diese Day-Two-Details sind oft genauso wichtig wie Abfragegeschwindigkeit.

Wie man den richtigen Datenbanktyp wählt

Die Wahl zwischen den großen Datenbanktypen hängt weniger davon ab, was gerade im Trend ist, als davon, was du wirklich mit deinen Daten tun musst. Praktisch startest du, indem du rückwärts von deinen Abfragen und Workloads arbeitest.

1) Fang bei deinen Abfragen an (nicht bei den Daten)

Schreibe die 5–10 wichtigsten Dinge auf, die deine App oder dein Team tun muss:

• Was liest du am häufigsten (Single-Record-Lookups, Filter, Joins, Aggregationen, Similarity Search)?
• Was schreibst du am häufigsten (Single-Row-Inserts, Event-Streams, Updates, Bulk-Loads)?
• Wie frisch müssen Ergebnisse sein (Millisekunden, Sekunden, Minuten)?

Das grenzt Optionen schneller ein als jede Feature-Checkliste.

2) Passe die DB an deine Datenform an

Schnelle Checkliste:

• Strukturierte, konsistente Felder → relationale Datenbank
• Semi-strukturierte JSON, das sich oft ändert → Dokumentdatenbank
• Viele-zu-viele-Beziehungen, die tief traversiert werden → Graphdatenbank
• Embeddings und Nearest-Neighbor-Suche → Vektor-Datenbank
• Events/Metriken mit Zeitstempel und Rollups → Time-Series-Datenbank
• Riesige scale-out Tabellen mit vorhersehbaren Zugriffsmustern → Wide-Column-Datenbank
• Sehr einfaches Get/Set per Key → Key-Value-Store
• Schwere Analytics-Scans und Aggregationen → Columnar Database (oder Warehouse)

3) Kläre Latenz, Durchsatz und Kostentreiber früh

Performance-Ziele definieren die Architektur. Setze grobe Zahlen (p95 Latenz, Reads/Writes pro Sekunde, Datenaufbewahrung). Kosten folgen oft aus:

• Storage (Rohdaten + Replikate)
• Compute (Queries, ETL/ELT, Background-Jobs)
• Replikation (Multi-Region, HA)
• Indizierung (schnellere Abfragen, mehr Schreib-Overhead)

4) Eine einfache Entscheidungstabelle

Viele Teams nutzen zwei Datenbanken: eine für Operationen (z. B. relational) und eine für Analytics (z. B. columnar/warehouse). Die „richtige" Wahl macht deine wichtigsten Abfragen am einfachsten, schnellsten und günstigsten zuverlässig auszuführen.

Ein praktischer Hinweis beim schnellen Produktbau

Beim Prototyping oder schnellen Feature-Shipping ist die Datenbankentscheidung oft an deinen Entwicklungsworkflow gekoppelt. Plattformen wie Koder.ai (eine Vibe-Coding-Plattform, die Web-, Backend- und Mobile-Apps aus Chat generiert) können das konkreter machen: Beispielsweise verwendet Koder.ai als Default-Backend-Stack Go + PostgreSQL, was ein starker Startpunkt ist, wenn du transaktionale Korrektheit und breites SQL-Tooling brauchst.

Wenn dein Produkt wächst, kannst du spezialisierte Datenbanken hinzufügen (z. B. eine Vektor-Datenbank für semantische Suche oder ein Columnar-Warehouse für Analytics), während PostgreSQL als System of Record bleibt. Wichtig ist, mit den Workloads zu starten, die du heute unterstützen musst — und die Tür offen zu halten für "einen zweiten Store hinzufügen", wenn die Abfragemuster es verlangen.