4. DBMS Markt

Marktübersicht der Datenbankmanagementsysteme

In der modernen Softwarewelt bilden Datenbankmanagementsysteme eine Art unsichtbare Infrastruktur: Sie speichern und ordnen die Daten, von denen fast jede Anwendung abhängt. Dabei gibt es nicht die eine Datenbank, sondern ein ganzes Ökosystem unterschiedlicher Systeme, jedes optimiert für bestimmte Datenarten und Lasten.

Markt der Datenbankmanagementsysteme. — Abb. 4.1: Marktgröße für Datenbankmanagementsysteme 2024–2030

Quelle: [9]

Die Grafik zeigt den weltweiten DBMS-Markt nach Regionen von 2018 bis 2030. Das Gesamtvolumen wächst stetig von knapp unter 50 Milliarden USD im Jahr 2018 auf rund 100 Milliarden USD im Jahr 2023.

Regional bleibt Nordamerika (dunkelviolett) über den gesamten Zeitraum das größte Segment, gefolgt von Europa und dem asiatisch-pazifischen Raum. Der Anteil von Asien-Pazifik wächst sichtbar und trägt in den späteren Jahren einen großen Teil des Zuwachses bei, während Europa ebenfalls zulegt, aber etwas moderater. Lateinamerika sowie der Nahe Osten und Afrika bleiben vergleichsweise kleine Segmente, wachsen aber mit dem Gesamtmarkt allmählich mit.

Jahr	DBMS-Markt gesamt	Anteil relational	Anteil nicht-relational (v. a. NoSQL)
2022	78,5 Mrd. USD	> 74 %	< 26 %
2023	100,79 Mrd. USD	> 62 %	< 38 %
2024	114,99 Mrd. USD	≈ 61,8 %	≈ 38,2 %

Tabelle 4.1: Geschätzter Marktanteil relationaler gegenüber NoSQL-Datenbanken (Quelle: [9])

Relationale Datenbanksysteme: der klassische Kern

Relationale Datenbanksysteme sind der klassische, gut etablierte Kern der Datenbankwelt. Daten liegen in Tabellen mit Zeilen und Spalten; jede Tabelle beschreibt eine Art von Entität, etwa customers, orders oder products. Die Beziehungen zwischen diesen Tabellen werden über primary keys und foreign keys ausgedrückt.

Relationales Datenbankmanagementsystem. — Abb. 4.2: Relationale Datenverwaltung

Zu den bekanntesten zählen PostgreSQL, MySQL und MariaDB auf der Open-Source-Seite sowie Oracle Database, Microsoft SQL Server und IBM DB2 auf der proprietären Seite. Angesprochen werden all diese Systeme über SQL, die Structured Query Language, die Standardsprache für die Verwaltung und Abfrage relationaler Datenbanken.

Ein zentrales Merkmal relationaler Systeme ist die Unterstützung von ACID-Transaktionen (Atomicity, Consistency, Isolation, Durability). Eine Folge von Änderungen, etwa eine Überweisung zwischen Bankkonten oder die Buchung eines Flugsitzes, wird dadurch entweder vollständig ausgeführt oder gar nicht. Die Datenbank bleibt selbst bei Fehlern in einem konsistenten Zustand. Für viele klassische betriebliche Anwendungen, von ERP-Systemen über Lagerverwaltung, Finanzen und Personalwesen bis zu zahlreichen Web-Backends, macht diese Kombination aus starken Garantien, ausgereiften Werkzeugen und mächtigen Abfragemöglichkeiten relationale Datenbanken zur Standardwahl.

Das Modell hat aber auch Grenzen:

Durch das starre Schema lassen sich sehr flexible oder schnell wechselnde Datenstrukturen schwerer speichern.
Horizontale Skalierung über Hunderte oder Tausende Maschinen ist möglich, aber oft aufwendig.

Genau das starre Schema und die starken Konsistenzgarantien sind zugleich der Grund, warum relationale Datenbanken in vielen Unternehmensanwendungen dominant bleiben, überall dort, wo Datenintegrität und komplexe Abfragen entscheidend sind.

Vorteile relationaler Datenbankmanagementsysteme (RDBMS)

Starke Datenintegrität und Konsistenz (ACID-Transaktionen)
- RDBMS sind um ACID-Garantien herum gebaut (Atomicity, Consistency, Isolation, Durability).
- Das ist ideal, wenn Daten unbedingt immer korrekt und konsistent sein müssen (etwa Banking, Lagerbestand, Noten).
Mächtige, standardisierte Abfragesprache (SQL)
- SQL ist ausdrucksstark, deklarativ und über viele Systeme hinweg standardisiert (PostgreSQL, MySQL, SQL Server usw.).
- Komplexe Joins, Aggregationen, Subqueries oder Fensterfunktionen gehören zum Standardrepertoire, was in NoSQL oft schwieriger oder umständlicher ist.
Klares, erzwungenes Schema (Disziplin im Datenmodell)
- Tabellen, Spalten, Datentypen und Constraints (NOT NULL, UNIQUE, FOREIGN KEY, CHECK …) erzwingen Struktur auf Datenbankebene.
- Das reduziert inkonsistente oder „schmutzige” Daten und nimmt dem Anwendungscode viele Prüfungen ab.
Ausgereifte Werkzeuge und ein großes Ökosystem
- RDBMS haben Jahrzehnte an Optimierung hinter sich: Query-Planner, Indizes, Profiling-Werkzeuge, Backup und Restore, Replikation, Migrationswerkzeuge, ORMs und mehr.
- Erfahrene Datenbankadministratorinnen, Dokumentation und Community-Wissen sind leichter zu finden.

NoSQL als Sammelbegriff für alternative Modelle

Ab etwa Ende der 2000er-Jahre wurde der Begriff „NoSQL” bekannt. Streng genommen bedeutet er nicht „kein SQL”, sondern „Not only SQL”. Die Idee: Neben dem relationalen Ansatz gibt es andere Modelle, die für bestimmte Szenarien besser passen, vor allem für große Webanwendungen, Big-Data-Analysen oder sehr flexible, sich schnell verändernde Daten.

Unter dem NoSQL-Dach werden mehrere Familien zusammengefasst, unter anderem:

Dokumentendatenbanken
Key-Value-Stores
Graphdatenbanken und
Zeitreihendatenbanken
… und weitere.

Diese Systeme setzen oft auf horizontale Skalierbarkeit, flexible Schemata oder spezialisierte Zugriffsmuster statt auf strenge relationale Konsistenz. Für Skalierung und Performance lockern viele NoSQL-Systeme einige ACID-Eigenschaften und setzen auf eventual consistency oder andere Modelle.

Dokumentenorientierte Datenbanken: JSON als natürliches Format

Dokumentenorientierte Datenbanken behandeln Daten als Dokumente, meist als JSON-Dokumente oder in einem ähnlichen Format. Statt die Information über viele normalisierte Tabellen zu verteilen, beschreibt ein einzelnes Dokument eine ganze Entität, möglicherweise mit verschachtelten Strukturen. Ein order-Dokument könnte etwa Kundendaten, die Produktliste, Versandinformationen und Statusänderungen in einer verschachtelten Struktur enthalten.

Abb. 4.3: MongoDB Logo

Ein Beispiel-order-Dokument in einer Dokumentendatenbank könnte so aussehen:

{
  _id: ObjectId("675f4ef49b09f4a0e8a4b001"),
  orderNumber: "ORD-1234",
  createdAt: ISODate("2025-12-03T09:15:23Z"),
  status: "pending",

  customer: {
    customerId: ObjectId("675f4ef49b09f4a0e8b2a111"),
    name: "Andrea Hofer",
    email: "[email protected]"
  },

  shippingAddress: {
    street: "12 Sample Street",
    city: "Villach",
    postalCode: "9500",
    country: "AT"
  },

  items: [
    {
      productId: ObjectId("675f4ef49b09f4a0e8c30001"),
      name: "Wireless Mouse",
      quantity: 1,
      price: 19.99,
      currency: "EUR"
    },
    {
      productId: ObjectId("675f4ef49b09f4a0e8c30002"),
      name: "Mouse Pad",
      quantity: 1,
      price: 5.99,
      currency: "EUR"
    }
  ],

  totals: {
    subtotal: 25.98,
    currency: "EUR"
  }
}

MongoDB und CouchDB sind Vertreter dieser Kategorie. In solchen Systemen können verschiedene Dokumente derselben Collection leicht unterschiedliche Felder haben; das Schema ist flexibel oder sogar völlig dynamisch. Diese Flexibilität erleichtert es, das Datenmodell einer Anwendung ohne aufwendige Migrationen weiterzuentwickeln.

Abb. 4.4: CouchDB Logo

Abgefragt wird nicht mit SQL, sondern mit einer dokumentenspezifischen Abfragesprache oder einer API, die mit JSON-artigen Filtern und Aggregation-Pipelines arbeitet. Dokumentendatenbanken sind attraktiv, wenn Daten von Natur aus als JSON vorliegen, etwa in vielen Web- und Mobile-Anwendungen, oder wenn sich die Struktur häufig ändert, wie bei Content-Management-Systemen, Produktkatalogen oder Logging. Eine Abfrage, die im Aggregation Framework von MongoDB die fünf umsatzstärksten Kunden aus Elektronik-Bestellungen von 2024 sucht, sieht so aus:

db.orders.aggregate([
  // orders in 2024
  {
    $match: {
      orderDate: {
        $gte: ISODate("2024-01-01T00:00:00Z"),
        $lt:  ISODate("2025-01-01T00:00:00Z")
      }
    }
  },

  // one document per order line item
  { $unwind: "$items" },

  // join products (to filter by category)
  {
    $lookup: {
      from: "products",
      localField: "items.productId",
      foreignField: "_id",
      as: "product"
    }
  },
  { $unwind: "$product" },

  // electronics only
  { $match: { "product.category": "Electronics" } },

  // group by customer: revenue + quantity
  {
    $group: {
      _id: "$customerId",
      totalRevenue: {
        $sum: { $multiply: ["$items.quantity", "$items.unitPrice"] }
      },
      totalQuantity: { $sum: "$items.quantity" }
    }
  },

  // join customers for name + country
  {
    $lookup: {
      from: "customers",
      localField: "_id",
      foreignField: "_id",
      as: "customer"
    }
  },
  { $unwind: "$customer" },

  // final shape
  {
    $project: {
      _id: 0,
      customerId: "$_id",
      customerName: "$customer.name",
      country: "$customer.country",
      totalRevenue: 1,
      totalQuantity: 1
    }
  },

  // Top 5
  { $sort: { totalRevenue: -1 } },
  { $limit: 5 }
]);

Vorteile von Dokumentendatenbanken

Flexibles Schema („schema-less”)
- Man muss kein starres Schema wie in SQL vorab festlegen.
- Felder lassen sich pro Dokument ohne Migration hinzufügen oder entfernen.
- Sehr praktisch in laufenden Projekten oder wenn die Anforderungen noch unklar sind (typisch in der Webentwicklung).
Passt natürlich zu JSON und Anwendungsobjekten
- Dokumente sind im Grunde JSON und passen perfekt zu JavaScript- und TypeScript-Backends und -Frontends.
- Oft lassen sich Daten fast in derselben Struktur speichern, die man im Code verwendet, also weniger Mapping und weniger Reibung.
Gut für verschachtelte Daten (weniger Joins)
- Zusammengehörige Daten lassen sich direkt einbetten (wie customer, items, totals im order-Beispiel).
- Viele Lesevorgänge werden zu einer einzigen Abfrage statt mehrerer Joins über Tabellen hinweg, was leselastige Zugriffe deutlich beschleunigt.
Einfache horizontale Skalierung und hohe Verfügbarkeit
- Dokumentenspeicher sind von Anfang an auf Sharding und Replikation ausgelegt.
- Sie über mehrere Maschinen zu verteilen und hochverfügbar zu betreiben, ist vergleichsweise unkompliziert.
Schnelle Entwicklung und Iteration
- Durch flexibles Schema, JSON und weniger Joins kann man schnell iterieren, gerade in frühen Phasen oder bei Prototypen.
- Bei geänderten Anforderungen passt man oft nur den Code an und lässt die Datenbank mitwachsen.

Key-Value-Stores: Einfachheit für maximale Geschwindigkeit

Key-Value-Datenbanken haben das einfachste Modell: Jedes Datum wird unter einem eindeutigen Schlüssel gespeichert und über diesen Schlüssel wieder gelesen. Konzeptionell verhält sich das ganze System wie ein sehr großes, verteiltes Wörterbuch oder eine Hash-Map.

Abb. 4.5: Redis Logo

Redis ist ein prominentes Beispiel, das meist primär im Arbeitsspeicher arbeitet, aber optional persistieren kann. Amazon DynamoDB ist ein weiteres wichtiges System, das eine Key-Value- und dokumentenartige API als vollständig verwalteten Cloud-Dienst bietet.

Wegen ihrer Einfachheit sind Key-Value-Stores extrem schnell und gut skalierbar. Sie kommen dort zum Einsatz, wo einfache Zugriffsmuster überwiegen: Caching häufig genutzter Daten, Speichern von Benutzersitzungen, Feature-Flags oder Zähler und Warteschlangen mit sehr hohem Durchsatz. In vielen Architekturen ersetzt ein Key-Value-Store keine relationale Datenbank, sondern ergänzt sie, etwa als Caching-Schicht vor einem langsameren, aber funktionsreicheren System.

Typischer Aufbau eines Redis-Key-Value-Stores. — Abb. 4.6: So arbeitet Redis typischerweise: Zuerst (1) fragt der Anwendungsserver Redis nach einem Wert über den Schlüssel. Wird der Wert nicht gefunden (Cache Miss), holt er ihn (2) aus der primären Datenbank, gibt ihn an den Anwendungsserver zurück und legt ihn (3) für künftige Anfragen in Redis ab.

Quelle: [11]

Vorteile von Key-Value-Stores

Sehr hohe Performance und niedrige Latenz
- Daten liegen meist im Arbeitsspeicher, Lesen und Schreiben sind daher extrem schnell.
- Gut für Fälle, in denen Millisekunden (oder Mikrosekunden) zählen (Caching, Echtzeitanalysen, Gaming usw.).
Einfaches Datenmodell
- Nur key → value. Leicht zu verstehen, leicht zu benutzen.
- Keine komplexen Schemata, Joins oder Beziehungen.
Einfache horizontale Skalierung
- Key-Value-Stores lassen sich meist leicht nach Schlüssel über viele Knoten partitionieren/sharden.
- Das macht das Skalieren auf große Lasten unkompliziert.
Ideal für Caching
- Perfekt als Cache vor einer anderen Datenbank oder API.
- Eingebaute TTL (Time-to-live) und Eviction-Strategien lassen alte Daten automatisch ablaufen.
Atomare Operationen und Nebenläufigkeit
- Viele Operationen sind atomar (z. B. INCR, DECR, Push/Pop auf Listen), was gleichzeitige Aktualisierungen vereinfacht.
- Sehr nützlich für Rate Limiting, verteilte Locks und Zähler.
Zusatzfunktionen über reines Speichern hinaus
- Redis bietet Pub/Sub, Streams, Lua-Scripting und mehr.
- Damit lässt es sich als Message Broker, Event-Stream oder Koordinationsdienst nutzen.

Graphdatenbanken: der Fokus liegt auf Beziehungen

Graphdatenbanken entstanden aus der Beobachtung, dass in vielen Problemfeldern die Beziehungen zwischen Entitäten mindestens so wichtig sind wie die Entitäten selbst, manchmal sogar wichtiger. Soziale Netzwerke, Empfehlungssysteme und Netzwerkanalysen leben von komplexen Beziehungsmustern.

Abb. 4.7: Neo4j Logo

In einer Graphdatenbank wie Neo4j werden Daten als Knoten (Entitäten wie Personen, Produkte oder Geräte) und Kanten (Beziehungen wie „ist befreundet mit”, „hat gekauft”, „verbunden mit”) modelliert. Sowohl Knoten als auch Kanten tragen Eigenschaften. Abfragen beschreiben Muster im Graphen, etwa: „Finde alle Personen, die mit jemandem befreundet sind, der Produkt X gekauft und auch Produkt Y gemocht hat.”

Dieses Modell spielt seine Stärke dort aus, wo mehrstufige Beziehungen und Traversierungen häufig und performancekritisch sind. Relationale Datenbanken könnten Graphen zwar über Verbindungstabellen abbilden, doch Abfragekomplexität und Performance werden ungünstig, sobald die Traversierungen tief und unregelmäßig werden. Für diese speziellen, aber wichtigen Fälle bieten Graphdatenbanken eine natürlichere und effizientere Lösung.

Ein Cypher-Beispiel, um Freundinnen von Freundinnen in einem sozialen Graphen zu finden:

// create a few people and friendships
CREATE (alice:Person {name: "Alice"})
CREATE (bob:Person   {name: "Bob"})
CREATE (carol:Person {name: "Carol"})

CREATE (alice)-[:FRIENDS_WITH]->(bob)
CREATE (bob)-[:FRIENDS_WITH]->(carol);

// find friends of Alice's friends
MATCH (a:Person {name: "Alice"})-[:FRIENDS_WITH]->(:Person)-[:FRIENDS_WITH]->(fof)
RETURN fof.name AS friendOfFriend;

Vorteile von Graphdatenbanken

Natürliche Modellierung stark vernetzter Daten
- Knoten = Entitäten, Beziehungen = Kanten.
- Soziale Netzwerke, Empfehlungssysteme, Identitäts- und Zugriffsgraphen, Netzwerktopologien oder Wissensgraphen bilden sich direkt im Datenmodell ab.
Schnelles Traversieren von Beziehungen
- Abfragen über viele Schritte (Freundinnen von Freundinnen, kürzester Pfad, gemeinsame Nachbarn) sind deutlich schneller und einfacher als in relationalen oder Key-Value-Systemen.
- Kanten sind „erstklassige” Objekte und werden meist mit effizienten Zeigern gespeichert.
Ausdrucksstarke, beziehungsorientierte Abfragesprachen
- Sprachen wie Cypher sind um Mustererkennung herum entworfen: (a)-[:KNOWS]->(b) ist wörtlich die Abfragesyntax.
- Komplexe Graphfragen (Pfade, Muster, Nachbarschaften) werden kurz und lesbar.
Flexibles Schema, einfache Weiterentwicklung
- Neue Knoten- oder Beziehungstypen und Eigenschaften lassen sich ohne schmerzhafte Migrationen ergänzen.
- Gut, wenn sich die Domäne verändert oder man mit der Zeit neue Zusammenhänge entdeckt.
Eingebaute Graph-Algorithmen und -Analysen
- Viele Graphdatenbanken (Neo4j usw.) bieten Bibliotheken für Zentralität (PageRank), Community-Erkennung, Ähnlichkeit oder kürzeste Pfade.
Besserer Blick auf Beziehungen und Struktur
- Das Modell lädt dazu ein, in Verbindungen und Strukturen zu denken, nicht nur in Zeilen und Spalten.
Weniger Join-Chaos bei beziehungslastigen Abfragen
- In einem RDBMS bräuchte man mehrere Joins über Verbindungstabellen; in einer Graphdatenbank traversiert man einfach Kanten.
- Das vereinfacht Schema und Abfragelogik für stark vernetzte Domänen.

Zeitreihendatenbanken: Zeit als erstklassiges Thema

Zeitreihendatenbanken sind auf Daten spezialisiert, die vor allem um die Zeit herum strukturiert sind: Messwerte, Sensordaten, Log-Einträge, Aktienkurse oder andere Werte, die sich über die Zeit ändern. In solchen Systemen besteht ein Datensatz typischerweise aus einem Zeitstempel, einem oder mehreren Messwerten und zusätzlichen Labels oder Tags, die die Quelle der Messung beschreiben.

Abb. 4.8: InfluxDB Logo

Systeme wie InfluxDB, TimescaleDB oder Prometheus fallen in diese Kategorie. Sie sind auf extrem hohe Schreibraten optimiert, denn Monitoring- und IoT-Systeme erzeugen leicht Tausende oder Millionen Messwerte pro Sekunde. Sie bieten außerdem effiziente Mechanismen, um alte Daten herunterzurechnen (Downsampling) oder zu löschen, und hoch optimierte Abfragen für Zeiträume, Durchschnitte, Maxima, Perzentile und ähnliche Aggregationen.

In Monitoring-Szenarien für Server, Anwendungen, Netzwerke oder smarte Geräte bilden Zeitreihendatenbanken oft das Rückgrat von Dashboards und Alarmsystemen. Relationale oder Dokumentendatenbanken können Zeitreihen zwar speichern, erreichen aber bei sehr großen Datenmengen und zeitbasierten Abfragen selten die Performance und den Komfort spezialisierter Engines.

Das folgende Grafana-Dashboard (https://grafana.com/) zeigt ein Beispiel für die Visualisierung von Zeitreihendaten.

Beispiel eines Grafana-Dashboards. — Abb. 4.9: Beispiel eines Grafana-Dashboards

Vorteile von Zeitreihendatenbanken

Optimiert für zeitgestempelte Daten
- Datenmodell, Speicher-Engine und Indizes sind auf (measurement, tags, fields, timestamp) ausgelegt.
- Deutlich effizienter für Messwerte, Logs, Sensordaten oder Kursticks als eine „generische” Tabelle.
Hoher Schreibdurchsatz
- Zeitreihendatenbanken bewältigen riesige Mengen an Inserts pro Sekunde (etwa Messwerte von Tausenden Servern, Sensoren, IoT-Geräten).
- Gebündelte, komprimierte Schreibvorgänge und Append-only-Formate sind üblich.
Effiziente Kompression und Speicherung
- Zeitreihenbewusste Kompression (etwa Delta- oder Run-Length-Encoding) speichert große Mengen günstig.
- Man kann viel längere Historien (Monate, Jahre) vorhalten, ohne dass der Speicher explodiert.
Eingebaute Aufbewahrungsregeln und Downsampling
- Man kann Regeln definieren wie: „Rohdaten 7 Tage behalten, 1-Minuten-Durchschnitte 30 Tage, 1-Stunden-Durchschnitte 1 Jahr.”
- Alte Daten werden automatisch aggregiert und/oder gelöscht, also keine manuellen Aufräumskripte.
Zeitreihenfreundliche Abfragesprache und Funktionen
- Aggregationen über Zeitfenster: MEAN(), SUM(), MAX() usw., gruppiert nach Zeitfenstern (GROUP BY time(1m)).
- Eingebaute Funktionen für gleitende Durchschnitte, Raten (Ableitungen), Fensterung oder Interpolation.
Gute Integration mit Monitoring und Dashboards
- Zeitreihendatenbanken lassen sich gut mit Werkzeugen wie Grafana kombinieren.
- Dashboards für Systemmetriken, Business-KPIs oder IoT-Telemetrie sind schnell gebaut.

Eingebettete und In-Process-Datenbanken: Datenbanken, die mit der Anwendung reisen

Nicht jede Anwendung braucht einen eigenen Datenbankserver auf einer eigenen Maschine oder in einem eigenen Container. In vielen Fällen, besonders bei Desktop-Anwendungen, mobilen Apps oder kleinen Werkzeugen, ist eine eingebettete Datenbank passender, die im selben Prozess wie die Anwendung läuft.

Abb. 4.10: SQLite Logo

SQLite ist das weltweit bekannteste Beispiel: Es läuft gar nicht als Server, sondern speichert seine Daten in einer einzigen Datei und wird über eine Bibliothek direkt in die Anwendung eingebunden. Weitere eingebettete Datenbanken im Java-Umfeld sind H2 oder Derby. Solche Systeme bieten oft eine Teilmenge relationaler Funktionen, aber in sehr leichtgewichtiger Form.

Eingebettete Datenbanken sparen den Aufwand, einen eigenen Server aufzusetzen und zu betreiben. Sie eignen sich für offlinefähige Anwendungen, lokale Datenspeicherung auf Geräten, Prototyping oder automatisierte Tests. Selbst in großen Webanwendungen taucht SQLite noch in Entwicklungsumgebungen auf, während in der Produktion ein schwereres relationales System läuft.

Abb. 4.11: SQLite-Architektur im Vergleich zu klassischen Client-Server-RDBMS.

Quelle: [10]

Trotz seiner Leichtgewichtigkeit bietet SQLite vollständiges SQL mit ACID-Semantik. Man bekommt Tabellen, Indizes, Transaktionen, Constraints und all die relationalen Vorzüge, die man auch bei größeren RDBMS lernt. Für viele Lasten, besonders leselastige Einzelnutzer-Szenarien, kann SQLite überraschend schnell sein, weil Netzwerk-Roundtrips und Kontextwechsel zwischen Client und Server entfallen. Die Daten sind einfach eine Datei im lokalen Dateisystem, und die Engine ist auf kleine, schnelle Transaktionen und Abfragen optimiert.

In-Process-Datenbanken zeigen ihre Grenzen aber bei Nebenläufigkeit und Skalierung. SQLite nutzt Sperrstrategien auf Dateiebene; hohe Schreibnebenläufigkeit (viele gleichzeitige Schreiber) skaliert damit längst nicht so gut wie ein serverbasiertes RDBMS, das viele parallele Clients und komplexes Locking bewältigt. Klassische Client-Server-Datenbanken sind darauf ausgelegt, viele Clients zu koordinieren, komplexe Transaktionen zu verwalten und Last über mehrere Kerne und sogar mehrere Maschinen zu verteilen.

Ein weiterer wichtiger Unterschied liegt in der Betriebstopologie und den Sicherheitsfunktionen. Ein serverbasiertes RDBMS unterstützt Verbindungen von mehreren Hosts, Benutzerverwaltung, Rollen, feingranulare Rechte, Replikation und Hochverfügbarkeit. Man kann die Daten zentralisieren, Backups und Monitoring auf dem Datenbankserver betreiben und ihn sicher im Netzwerk bereitstellen. SQLite hat konstruktionsbedingt keine „Remote-Access”-Schicht: Der Anwendungsprozess braucht direkten Zugriff auf die Datenbankdatei.

Vorteile von In-Process-Datenbanken

Kein Aufsetzen, keine Administration
- Kein separater Server zu installieren, konfigurieren oder betreiben.
- Die App bindet einfach die SQLite-Bibliothek ein und nutzt eine einzige .db-Datei, ideal für Endanwender und einfache Deployments.
Einfaches Deployment und Portabilität
- Die ganze Datenbank ist meist eine Datei, die man kopieren, verschieben oder mit der App bündeln kann.
- Das macht Backups, Umzüge auf andere Maschinen oder „portable Apps” sehr einfach.
Gute Performance für lokale Einzelnutzer-Lasten
- Keine Netzwerk-Roundtrips: Abfragen laufen im selben Prozess wie die Anwendung.
- Sehr schnell bei leselastigen oder kleinen Schreiblasten auf einem einzelnen Gerät.
Vollständiges SQL und ACID im Miniformat
- Trotz „leichtgewichtig” bietet SQLite echte Tabellen, Indizes, Constraints und Transaktionen.
Ideal für eingebettete und Offline-Szenarien
- Perfekt für mobile Apps, Desktop-Werkzeuge, IoT-Geräte und Offline-first-Apps, die ohne Netzwerk funktionieren müssen.
- Die App kann die SQLite-Datei (oder ausgewählte Daten) synchronisieren, sobald eine Verbindung besteht.
Geringere Betriebskomplexität und Kosten
- Kein Bedarf an DB-Administration, Monitoring eines DB-Servers oder Verwaltung von Remote-Verbindungen.
- Reduziert Infrastruktur- und Wartungsaufwand insgesamt.

Open Source und proprietär: unterschiedliche Modelle für Entwicklung und Lizenzierung

Über die technischen Unterschiede hinaus lässt sich der Datenbankmarkt auch nach Lizenz- und Entwicklungsmodell einteilen. Open-Source-Datenbanken veröffentlichen ihren Quellcode unter Lizenzen, die freie Nutzung, Veränderung und Weitergabe erlauben. PostgreSQL, MySQL, MariaDB, SQLite, MongoDB Community Edition, Redis, Cassandra und viele andere gehören dazu.

Abb. 4.12: Microsoft SQL Server Logo

Open-Source-Datenbanken profitieren oft von großen Communities, einem reichen Ökosystem an Werkzeugen und Bibliotheken und dem Wegfall klassischer Lizenzgebühren. Organisationen können sie auf eigener Infrastruktur betreiben oder verwaltete Angebote von Cloud-Anbietern nutzen. Manche Hersteller verfolgen ein „Open-Core”-Modell, bei dem der Kern der Datenbank quelloffen bleibt, zusätzliche Enterprise-Funktionen aber nur in einer kostenpflichtigen Edition verfügbar sind.

Abb. 4.13: Oracle Database Logo.

Proprietäre Systeme wie Oracle Database, Microsoft SQL Server, IBM DB2, SAP HANA oder Snowflake werden dagegen von Unternehmen entwickelt und lizenziert, die den vollständigen Quellcode nicht veröffentlichen. Diese Produkte setzen typischerweise auf Enterprise-Funktionen wie fortgeschrittenes Clustering, integrierte Werkzeuge, enge Abstimmung mit anderen Bausteinen des Hersteller-Ökosystems (etwa Microsoft) und starken kommerziellen Support. Im Gegenzug fallen Lizenzgebühren an, oft gebunden an die Zahl der Kerne, Nutzer oder das verarbeitete Datenvolumen.

Abb. 4.14: IBM DB2 Logo.

Die Wahl zwischen Open Source und proprietär ist nicht rein technisch; Budget, Support-Erwartungen, Compliance-Anforderungen und bestehende Herstellerbeziehungen spielen ebenfalls eine Rolle.

Vorteile kommerzieller/proprietärer Datenbanken

Herstellersupport und SLAs
- Eigene Support-Teams, Hotlines rund um die Uhr, zugesicherte Reaktionszeiten (SLAs).
- Nützlich, wenn Ausfälle oder Datenverlust echte finanzielle oder rechtliche Folgen haben.
Fortgeschrittene Enterprise-Funktionen ab Werk
- Eingebaute Werkzeuge für Clustering, Hochverfügbarkeit, automatisches Failover, fortgeschrittene Replikation, Partitionierung, In-Memory-Optionen und mehr.
- Oft ausgereifter und leichter zu konfigurieren als selbstgebaute Lösungen rund um Open-Source-Systeme.
Integriertes Ökosystem und Werkzeuge
- GUI-Admin-Werkzeuge, Monitoring-Dashboards, Performance-Analysen, Migrationsassistenten und Backup-Lösungen, die aufeinander abgestimmt sind.
- Reduziert die Notwendigkeit, viele einzelne Open-Source-Werkzeuge zusammenzustecken.
Compliance, Zertifizierungen und Governance
- Kommerzielle Hersteller bieten oft Funktionen und Dokumentation für Compliance (DSGVO, HIPAA, PCI-DSS usw.).
- Audit-Logging, feingranulare Zugriffssteuerung, Verschlüsselung und Zertifizierungen können in regulierten Branchen wichtig sein.
Schulungen, Beratung und Partner
- Offizielle Schulungen, Zertifizierungen und Beratungsleistungen.
- Hilfreich für große Organisationen, die standardisierte Kenntnisse und Abläufe wollen.

Betriebsmodelle: von On-Premises bis „Database as a Service”

Eine weitere Achse betrifft, wie das System betrieben wird. Traditionell installieren Organisationen Datenbanken „on-premises” auf eigenen Servern, kümmern sich selbst um Backups, Updates und Skalierung und betreiben sie eventuell in virtuellen Maschinen oder Containern.

Mit dem Aufstieg des Cloud Computing werden viele Datenbanken auch als vollständig verwaltete Dienste angeboten. Amazon RDS, Azure SQL Database, Google Cloud SQL und ähnliche Dienste betreiben bekannte relationale Engines im Auftrag der Kunden und übernehmen Patching, Backups und Monitoring innerhalb der Infrastruktur des Anbieters. Stärker cloud-native Datenbanken wie DynamoDB, Cosmos DB, Bigtable oder Firestore sind eng an einen bestimmten Cloud-Anbieter gebunden und bieten automatische Skalierung, hohe Verfügbarkeit und nutzungsbasierte Abrechnung: DaaS (Database as a Service).

Vorteile von Database as a Service (DBaaS)

Keine Serverinstallation oder -wartung
- Der Anbieter kümmert sich um Betriebssystem, Datenbankinstallation, Patching, Upgrades und viele Konfigurationsdetails.
- Man braucht keine eigene DB-Administration nur, um die Datenbank am Leben und aktuell zu halten.
Automatische Backups und hohe Verfügbarkeit
- Eingebaute automatische Backups, Point-in-Time-Recovery und einfache Replikationsoptionen.
- Failover auf Replikate läuft oft automatisch, also mehr Verfügbarkeit bei weniger Aufwand.
Einfache Skalierung
- Meist kann man mit wenigen Klicks oder einem API-Aufruf hochskalieren (mehr CPU/RAM/Speicher).
- Manche Dienste unterstützen auch Herausskalieren (Read Replicas, Sharding), ohne alles neu zu entwerfen.
Nutzungsbasiertes Kostenmodell
- Man zahlt für das, was man nutzt (Instanzen, Speicher, I/O), statt Hardware vorab zu kaufen.
- Gut für Projekte mit unsicherer Last oder für Lern- und Experimentiersysteme.
Integrierte Sicherheits- und Compliance-Funktionen
- Verschlüsselung im Ruhezustand und bei der Übertragung, rollenbasierter Zugriff, Audit-Logs, VPC-/Netzwerkintegration.
- Sicherheits- und Compliance-Anforderungen sind leichter zu erfüllen, als alles selbst zu bauen.
Schnellere Time-to-Market
- Eine produktionsreife Datenbank ist in Minuten bereitgestellt.
- Teams können sich auf die Anwendungslogik konzentrieren statt auf Infrastruktur.

Wie sich die Typen in der Praxis kombinieren

In echten Systemen sieht man selten nur einen einzigen Datenbanktyp. Stattdessen kombinieren Architektinnen oft mehrere Systeme, jedes gewählt für seine Stärken. Eine Webanwendung nutzt vielleicht PostgreSQL als primäre relationale Datenbank für die Kerndaten, während Redis Caching und Session-Verwaltung übernimmt, Elasticsearch oder eine andere Suchmaschine die Volltextsuche bedient und eine Zeitreihendatenbank die Monitoring-Metriken sammelt.

Dieser polyglotte Ansatz akzeptiert, dass kein einzelnes System für alle Aufgaben ideal ist. Relationale, Dokumenten-, Key-Value-, Graph- und Zeitreihendatenbanken besetzen jeweils eine Nische, in der sie am besten arbeiten.