Vergleich der wichtigsten Datenbanktypen — relational, spaltenorientiert, dokument-, graph-, vektor- und key-value-Stores sowie Time-Series und Wide-Column — mit Anwendungsfällen, Vor- und Nachteilen und Tipps zur Auswahl.
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).
Verschiedene Datenbanktypen machen unterschiedliche Kompromisse:
Diese Designentscheidungen beeinflussen:
Dieser Artikel führt durch die wichtigsten Datenbanktypen und erklärt für jeden:
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.
Fange mit deinem Haupt-Workload an:
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 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.
Relationale Systeme werden typischerweise mit SQL (Structured Query Language) abgefragt. SQL ist beliebt, weil es lesbar und ausdrucksstark ist:
WHERE, ORDER BY).JOIN).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.
Relationale Datenbanken sind bekannt für ACID-Transaktionen, die helfen, Daten korrekt zu halten:
Das ist wichtig, wenn Fehler teuer sind — etwa doppelte Abbuchungen oder verlorene Lagerbestandsupdates.
Eine relationale Datenbank passt in der Regel für strukturierte, gut definierte Daten und Workflows wie:
Die gleiche Struktur, die relationale Datenbanken zuverlässig macht, kann Reibung erzeugen:
Wenn dein Datenmodell sich ständig ändert — oder du extreme horizontale Skalierung mit einfachen Zugriffsmustern brauchst — können andere Datenbanktypen besser passen.
Spaltenorientierte Datenbanken speichern Daten „pro Spalte" statt „pro Zeile". Diese Änderung hat großen Einfluss auf Geschwindigkeit und Kosten für Analytics-Workloads.
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.
Analytics- und BI-Abfragen:
SUM, AVG, COUNT und gruppieren nach DimensionenColumnar 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.
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.
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.
Spaltenorientierte Datenbanken sind stark für:
Wenn schnelle Aggregationen über viel Daten Priorität haben, ist Columnar meist der erste Typ, den man evaluiert.
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.
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.
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.
Dokumentdatenbanken glänzen bei sich entwickelnden Schemata, verschachtelten Daten und API-freundlichen Payloads. Die Tradeoffs zeigen sich oft bei:
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 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.
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).
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.
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.
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.
Key-Value-Stores passen gut für:
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 (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.
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.
Wide-Column-Systeme sind ausgelegt für:
Das häufigste Muster ist:
Das macht sie stark für zeitgeordnete Daten und append-lastige Workloads.
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.
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 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.
Ein Graph hat typischerweise:
So lassen sich Netzwerke, Hierarchien und viele-zu-vielen-Beziehungen natürlich darstellen, ohne das Schema zu verformen.
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.
Graphdatenbanken sind stark bei:
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.
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 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.
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.
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.:
Dieses „Filter + Similarity"-Muster macht Vektor-Suche praktikabel für reale Datensätze.
Typische Anwendungsfälle umfassen:
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.
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 (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.
Die meisten Zeitreihen-Einträge kombinieren:
Damit lassen sich Fragen wie „Fehlerquote nach Service anzeigen" oder „Latenz zwischen Regionen vergleichen" leicht stellen.
Da das Datenvolumen schnell wachsen kann, konzentrieren sich TSDBs typischerweise auf:
Diese Features halten Storage- und Query-Kosten vorhersagbar, ohne ständiges manuelles Aufräumen.
TSDBs sind stark, wenn du zeitbasierte Berechnungen brauchst, wie:
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.
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.
Die meisten Warehouses akzeptieren Daten auf zwei Wegen:
Warehouses sind für Analytics optimiert mit ein paar praktischen Tricks:
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.
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.
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?
Eine Faustregel:
Relationale DBs eignen sich oft für OLTP; Columnar-Systeme, Warehouses und Lakehouses sind häufige OLAP-Wahlen.
Wenn ein Netzwerkpartition auftritt, kannst du typischerweise nicht alle drei gleichzeitig haben:
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.
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.
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.
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.
Schreibe die 5–10 wichtigsten Dinge auf, die deine App oder dein Team tun muss:
Das grenzt Optionen schneller ein als jede Feature-Checkliste.
Schnelle Checkliste:
Performance-Ziele definieren die Architektur. Setze grobe Zahlen (p95 Latenz, Reads/Writes pro Sekunde, Datenaufbewahrung). Kosten folgen oft aus:
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.
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.
Ein „Datenbanktyp" ist eine Kurzbeschreibung für drei Dinge:
Die Wahl des Typs bedeutet im Kern, Standardannahmen für Performance, Kosten und Betriebskomplexität festzulegen.
Fange mit deinen top 5–10 Abfragen und Schreibmustern an und ordne sie dann den Stärken zu:
Relationale Datenbanken sind ein starker Default, wenn du brauchst:
Sie werden unangenehm, wenn du ständige Schemaänderungen hast oder extreme horizontale Skalierung mit vielen Join-lastigen Abfragen über Shards benötigst.
ACID ist eine Verfügbarkeitsgarantie für mehrstufige Änderungen:
ACID ist besonders wichtig, wenn Fehler teuer sind (Zahlungen, Buchungen, Inventaraktualisierungen).
Spaltenorientierte Datenbanken sind ideal, wenn Abfragen:
SUM, COUNT, , )Eine Dokumentdatenbank passt, wenn:
Beachte Tradeoffs bei komplexen Joins, möglicher Datenduplizierung für Leseperformance und den Kosten von Multi-Document-Transaktionen.
Verwende einen Key-Value-Store, wenn dein Zugriffsmuster meist ist:
Beachte Einschränkungen: Ad-hoc-Queries sind meist schwach, und Support für sekundäre Indizes variiert—häufig entwirfst du zusätzliche Lookup-Keys selbst.
Trotz ähnlichem Namen zielen sie auf unterschiedliche Workloads ab:
Wide-Column-Systeme erfordern typischerweise query-driven Modeling (Tabellen rund um die genauen Zugriffsmuster entwerfen) und sind nicht so flexibel wie SQL mit Joins.
Wähle eine Graphdatenbank, wenn deine Kernfragen Beziehungen betreffen, z. B.:
Graphen sind stark bei Traversals (Beziehungsdurchläufe), wo relationale Ansätze viele Joins benötigen würden. Der Nachteil ist das Lernen neuer Modellierungsprinzipien und Querysprachen (z. B. Cypher/Gremlin/SPARQL).
Eine Vektor-Datenbank ist für Ähnlichkeitssuche über Embeddings gedacht (numerische Repräsentationen von Bedeutung). Typische Anwendungen:
Sie ersetzt selten die primäre Datenbank: üblicherweise bleibt die Quelle der Wahrheit in einer relationalen/ dokumentbasierten DB, Embeddings und Vektor-Indizes in der Vektor-DB, und Ergebnisse werden zur vollständigen Datensatz-Auflösung wieder verbunden.
| Primärer Use Case | Häufige Wahl | Warum |
|---|
| Transaktionen, Rechnungen, Nutzerkonten | Relational (SQL) | Starke Constraints, Joins, Konsistenz |
| App-Daten mit sich entwickelnden Feldern | Dokument | Flexibles Schema, natürliches JSON |
| Echtzeit-Caching / Session-State | Key-Value-Store | Schnelle Lookups per Key |
| Clickstreams / Metriken über Zeit | Time-Series | Hohe Ingest-Rate + zeitbasierte Queries |
| BI-Dashboards, große Aggregationen | Columnar | Schnelle Scans + Kompression |
| Soziale/wissensbasierte Beziehungen | Graph | Effiziente Relationship-Traversals |
| Semantische Suche, RAG Retrieval | Vektor | Ähnlichkeitssuche über Embeddings |
| Massive operationale Daten bei Scale | Wide-Column | Horizontale Skalierung, vorhersehbare Queries |
Wenn du sowohl OLTP als auch Analytics brauchst, plane früh mit zwei Systemen (operationale DB + Analytics-DB).
AVGGROUP BYFür OLTP-Workloads mit häufigen kleinen Updates oder „hole einen Datensatz per ID“-Mustern sind Row-Stores oft besser geeignet.