Vertikale vs. horizontale Skalierung von Datenbanken

1. Zwei grundverschiedene Skalierungsstrategien

Vertikale Skalierung, auch Scale-up genannt, erhoeht die Kapazitaet einer einzelnen Datenbankinstanz durch mehr CPU-Kerne, mehr Arbeitsspeicher oder schnellere Festplatten. Horizontale Skalierung, auch Scale-out genannt, verteilt Daten und Last auf mehrere Instanzen, typischerweise durch Sharding oder Partitionierung. Beide Strategien loesen das Problem wachsender Last, aber auf fundamental unterschiedliche Weise, mit unterschiedlichen Kosten und Komplexitaetsgraden.

Der entscheidende Unterschied liegt in der Architekturkomplexitaet. Vertikale Skalierung erfordert keine Aenderung an Datenmodell, Anwendungslogik oder Abfragestruktur, sie ist im Kern ein Hardware-Upgrade. Horizontale Skalierung dagegen aendert grundlegend, wie Daten gespeichert und abgefragt werden: Joins ueber Shard-Grenzen hinweg werden teuer oder unmoeglich, Transaktionen ueber mehrere Shards erfordern zusaetzliche Koordination, und die Anwendung muss wissen, auf welchem Shard ein bestimmter Datensatz liegt.

Eine haeufige Fehleinschaetzung ist, horizontale Skalierung fruehzeitig einzufuehren, weil sie als moderner oder zukunftssicherer gilt. In der Praxis loest gut dimensionierte vertikale Skalierung die meisten Lastprobleme kleiner und mittlerer Anwendungen vollstaendig, bei deutlich geringerer Komplexitaet. Die Entscheidung sollte auf tatsaechlichen Engpaessen basieren, nicht auf der Annahme, dass verteilte Systeme grundsaetzlich besser skalieren.

2. Vertikale Skalierung: Grenzen und Vorteile

Der groesste Vorteil vertikaler Skalierung ist ihre Einfachheit. Ein groesserer Server mit mehr RAM erlaubt es der Datenbank, einen groesseren Anteil der aktiven Datenmenge im Speicher zu halten, was Festplattenzugriffe reduziert und Latenzen senkt. Mehr CPU-Kerne erlauben mehr parallele Abfragen, ohne dass Anwendungscode oder Datenmodell angepasst werden muessen. Fuer viele Anwendungen ist ein Upgrade auf eine groessere Instanz die schnellste und risikoaermste Massnahme gegen Performance-Probleme.

Die Grenze vertikaler Skalierung ist physisch und wirtschaftlich zugleich. Es gibt eine maximale Instanzgroesse, die ein Cloud-Anbieter oder die verfuegbare Hardware ueberhaupt bereitstellt, und die Kosten steigen bei hochwertigen Instanzen ueberproportional zur gewonnenen Leistung. Ein Server mit doppelt so vielen Kernen kostet oft mehr als doppelt so viel, waehrend der tatsaechliche Performance-Gewinn durch Kontextwechsel-Overhead und Speicherbandbreitengrenzen unter dem theoretischen Faktor bleibt.

Ein weiterer struktureller Nachteil: vertikale Skalierung erhoeht nicht die Verfuegbarkeit. Ein einzelner, wenn auch sehr leistungsfaehiger Server bleibt ein einzelner Ausfallpunkt. Faellt diese eine Instanz aus, steht die gesamte Datenbank still, unabhaengig davon, wie viel Leistung sie hatte. Fuer Verfuegbarkeit braucht es zusaetzlich Replikation, unabhaengig von der Frage vertikaler oder horizontaler Skalierung der Kapazitaet selbst.

-- Beispiel: Ressourcenverbrauch pruefen, bevor man vertikal skaliert
-- PostgreSQL: Cache-Trefferquote als Indikator fuer RAM-Bedarf
SELECT
    sum(heap_blks_hit) / nullif(sum(heap_blks_hit) + sum(heap_blks_read), 0) AS cache_hit_ratio
FROM pg_statio_user_tables;
-- Werte unter 0.99 deuten auf zu wenig RAM fuer die aktive Datenmenge hin

-- Aktive Verbindungen und deren CPU-relevante Zustaende
SELECT state, count(*), avg(extract(epoch FROM (now() - query_start))) AS avg_runtime_seconds
FROM pg_stat_activity
WHERE state != 'idle'
GROUP BY state;

3. Horizontale Skalierung: Sharding und Verteilung

Horizontale Skalierung verteilt Daten auf mehrere unabhaengige Datenbankinstanzen, sogenannte Shards. Jeder Shard enthaelt eine Teilmenge der Gesamtdaten, typischerweise aufgeteilt nach einem Shard-Key wie Kunden-ID oder geografischer Region. Anders als bei Read Replicas, die vollstaendige Kopien derselben Daten sind, besitzt jeder Shard einen eigenstaendigen, nicht redundanten Teil der Gesamtdatenmenge, wodurch sowohl Schreiblast als auch Speichervolumen tatsaechlich verteilt werden.

Der fundamentale Vorteil liegt in der theoretisch unbegrenzten Skalierbarkeit: neue Shards koennen hinzugefuegt werden, wenn die Datenmenge waechst, ohne dass eine einzelne Instanz die gesamte Last tragen muss. Grosse Anwendungen mit mehreren Terabyte an Daten und hoher Schreiblast, die selbst die groesste verfuegbare Einzelinstanz ueberfordern wuerden, kommen ohne horizontale Skalierung nicht aus.

Diese Skalierbarkeit hat einen Preis: die Anwendung muss wissen, welcher Shard fuer welche Anfrage zustaendig ist, meist ueber ein Routing-Layer, das den Shard-Key aus der Anfrage extrahiert. Abfragen, die Daten aus mehreren Shards zusammenfuehren muessen, etwa fuer globale Reports, erfordern entweder aufwendige Fan-out-Abfragen ueber alle Shards oder ein separates Analytics-System, das Daten aus allen Shards konsolidiert.

4. Die Wahl des Shard-Keys als kritische Entscheidung

Die Wahl des Shard-Keys ist die wichtigste und am schwersten rueckgaengig zu machende Entscheidung bei horizontaler Skalierung. Ein guter Shard-Key verteilt Last und Datenvolumen gleichmaessig ueber alle Shards und passt zu den haeufigsten Zugriffsmustern der Anwendung. Kunden-ID eignet sich oft gut fuer Multi-Tenant-Anwendungen, weil die meisten Anfragen ohnehin auf Daten eines einzelnen Kunden beschraenkt sind und damit auf einen einzigen Shard treffen.

Ein schlecht gewaehlter Shard-Key fuehrt zu sogenannten Hot Shards: einzelne Shards, die deutlich mehr Last tragen als andere, weil der gewaehlte Key die Daten ungleichmaessig verteilt. Ein Beispiel ist die Verwendung eines fortlaufenden Zeitstempels als Shard-Key: alle neuen Schreibzugriffe landen dann konsequent auf demselben, aktuellsten Shard, waehrend aeltere Shards kaum noch Last erhalten, ein Muster, das die gesamte Idee der Lastverteilung untergraebt.

Die Aenderung eines bestehenden Shard-Keys nach dem produktiven Start ist aufwendig und riskant, weil sie faktisch eine vollstaendige Neuverteilung aller Daten bedeutet, oft bei laufendem Betrieb. Deshalb lohnt es sich, die Wahl des Shard-Keys fruehzeitig anhand der erwarteten Zugriffsmuster zu durchdenken, statt sie als technisches Detail zu behandeln, das spaeter leicht korrigiert werden kann.

-- Beispiel: Shard-Zuordnung ueber Hash des Shard-Keys
-- (Pseudo-Logik, wie sie in einem Anwendungs-Router vorkommt)

-- Guter Shard-Key: gleichmaessige Verteilung durch Hashing
-- shard_id = hash(customer_id) % number_of_shards

-- Schlechter Shard-Key: monoton steigende Werte erzeugen Hot Shards
-- shard_id = created_at_timestamp % number_of_shards  -- NICHT empfohlen

-- Abfrage, die auf einen einzelnen Shard trifft (ideal)
SELECT * FROM orders WHERE customer_id = 48213;

-- Abfrage, die alle Shards treffen muss (Fan-out, teuer)
SELECT count(*) FROM orders WHERE status = 'pending';

5. Was horizontale Skalierung an Komplexitaet kostet

Joins ueber Shard-Grenzen hinweg sind der teuerste Nebeneffekt horizontaler Skalierung. Ein einzelner SQL-Join, der in einer nicht-geshardeten Datenbank eine einzige, effiziente Operation ist, wird bei geshardeten Daten entweder unmoeglich oder erfordert, dass die Anwendung Daten aus mehreren Shards laedt und im Anwendungscode selbst zusammenfuehrt. Das verschiebt Logik, die eigentlich in die Datenbank gehoert, in die Anwendungsschicht, mit entsprechendem Wartungsaufwand.

Transaktionen ueber mehrere Shards hinweg sind ein weiteres strukturelles Problem: klassische ACID-Transaktionen funktionieren nur innerhalb eines einzelnen Shards zuverlaessig. Operationen, die mehrere Shards atomar aendern muessen, erfordern verteilte Transaktionsmuster wie Two-Phase-Commit oder Saga-Pattern, beide mit eigenen Komplexitaets- und Fehlerkosten, die in einer nicht-geshardeten Datenbank schlicht nicht existieren wuerden.

Schema-Aenderungen muessen bei horizontaler Skalierung auf allen Shards konsistent ausgefuehrt werden, was Migrationen deutlich aufwendiger macht als bei einer einzelnen Instanz. Ein fehlgeschlagenes Migrationsskript auf einem von zwanzig Shards hinterlaesst ein inkonsistentes Gesamtsystem, das manuell erkannt und behoben werden muss, ein Risiko, das bei einer einzelnen Instanz nicht existiert.

6. Hybride Strategien: Skalieren in Stufen

In der Praxis ist die Entscheidung selten binaer. Eine sinnvolle Reihenfolge ist, zunaechst vertikale Skalierung bis an ihre wirtschaftliche und technische Grenze auszureizen, ergaenzt durch Read Replicas fuer Leseverkehr, bevor horizontale Skalierung ueberhaupt in Betracht gezogen wird. Diese Kombination deckt einen ueberraschend grossen Anteil realer Lastprofile ab, ohne die Komplexitaet von Sharding auf sich nehmen zu muessen.

Partitionierung innerhalb einer einzelnen Instanz ist ein oft uebersehener Zwischenschritt: Tabellenpartitionierung nach Datum oder Kategorie verteilt Daten physisch auf mehrere Speicherbereiche innerhalb derselben Datenbankinstanz, ohne die Komplexitaet eines echten verteilten Systems mit Shard-Routing einzufuehren. Das verbessert Abfrageperformance fuer grosse Tabellen erheblich, bleibt aber architektonisch eine einzelne, vertikal skalierte Instanz.

Erst wenn Schreiblast oder Datenvolumen die technischen Grenzen einer einzelnen, gut dimensionierten Instanz tatsaechlich uebersteigen, rechtfertigt sich der Sprung zu echter horizontaler Skalierung mit Sharding. Diese stufenweise Herangehensweise vermeidet, dass ein Team die Komplexitaetskosten verteilter Systeme traegt, ohne den entsprechenden Skalierungsbedarf tatsaechlich zu haben.

7. Anzeichen, dass vertikale Skalierung nicht mehr reicht

Ein verlaessliches Signal ist, wenn die naechstgroessere verfuegbare Instanzgroesse keinen proportionalen Performance-Gewinn mehr bringt, weil Engpaesse nicht mehr bei CPU oder RAM liegen, sondern strukturell in der Anzahl gleichzeitiger Schreibzugriffe, die eine einzelne Instanz physikalisch verarbeiten kann. Dieses Plateau zeigt sich typischerweise zuerst bei Schreiblast, seltener bei reinem Leseverkehr, der sich meist noch durch Read Replicas abfedern laesst.

Ein zweites Anzeichen ist die schiere Datenmenge: wenn die gesamte aktive Datenmenge selbst mit maximalem verfuegbarem RAM nicht mehr in den Speicher passt und Festplattenzugriffe zum dominanten Faktor werden, hilft weiteres vertikales Skalieren nur noch begrenzt. Ab mehreren Terabyte an aktiven, haeufig abgefragten Daten wird dieser Punkt fuer viele Workloads relevant.

Ein drittes, oft unterschaetztes Signal ist die Backup- und Wartungszeit: Backups, Indexaufbau oder grosse Schema-Migrationen auf einer sehr grossen einzelnen Instanz dauern proportional laenger und blockieren zunehmend den Betrieb. Wenn Wartungsfenster durch die schiere Groesse einer einzelnen Instanz unpraktikabel lang werden, ist das ein indirekter, aber deutlicher Hinweis, dass horizontale Skalierung ernsthaft geprueft werden sollte.

8. Migration von vertikal zu horizontal planen

Eine Migration von einer einzelnen, vertikal skalierten Instanz zu einem geshardeten System sollte niemals als Big-Bang-Umstellung erfolgen. Der bewaehrte Ansatz ist, zunaechst neue Daten nach dem geplanten Shard-Schema zu schreiben, waehrend bestehende Daten schrittweise im Hintergrund migriert werden, oft ueber Wochen oder Monate, mit kontinuierlicher Validierung der Datenkonsistenz zwischen altem und neuem System.

Feature-Flags und Dual-Write-Strategien erlauben es, einzelne Teile der Anwendung nach und nach auf das geshardete System umzustellen, waehrend andere Teile weiterhin die alte, ungeshardete Instanz nutzen. Dieser graduelle Uebergang reduziert das Risiko eines vollstaendigen Ausfalls erheblich, verlaengert aber die Migrationszeit und erfordert, dass beide Systeme fuer eine Uebergangszeit parallel korrekt funktionieren.

Wichtig ist, den gewaehlten Shard-Key vor Beginn der Migration ausfuehrlich anhand realer Produktionsdaten zu testen, nicht erst nach der Migration festzustellen, dass er zu Hot Shards fuehrt. Eine Testmigration mit einer repraesentativen Kopie der Produktionsdaten auf einem kleineren Cluster deckt solche Probleme fruehzeitig auf, bevor sie im produktiven Betrieb teuer korrigiert werden muessen.

9. Vertikale und horizontale Skalierung im Vergleich

Die folgende Tabelle stellt die wichtigsten Entscheidungskriterien zwischen vertikaler und horizontaler Skalierung gegenueber und hilft, die passende Strategie fuer den jeweiligen Anwendungsfall zu identifizieren.

In der Praxis zeigt sich, dass die meisten Anwendungen mit sorgfaeltig dimensionierter vertikaler Skalierung kombiniert mit Read Replicas deutlich laenger auskommen, als Teams anfangs annehmen. Der Schritt zu echter horizontaler Skalierung lohnt sich erst, wenn konkrete, gemessene Engpaesse das belegen, nicht aufgrund einer allgemeinen Annahme ueber zukuenftiges Wachstum.

10. Zusammenfassung

Die Entscheidung zwischen vertikaler und horizontaler Skalierung ist keine Frage der Trendlage, sondern eine Frage der tatsaechlichen Engpaesse. Vertikale Skalierung ist einfach, risikoarm und deckt einen ueberraschend grossen Teil realer Lastprofile ab, stoesst aber an physische und wirtschaftliche Grenzen. Horizontale Skalierung durchbricht diese Grenzen, kostet dafuer erhebliche Komplexitaet bei Joins, Transaktionen und Schema-Migrationen.

Die Wahl des Shard-Keys ist die kritischste Einzelentscheidung bei horizontaler Skalierung und sollte fruehzeitig anhand echter Zugriffsmuster getestet werden, weil eine spaetere Korrektur teuer und riskant ist. Eine stufenweise Herangehensweise, vertikale Skalierung und Read Replicas zuerst ausreizen, dann gezielt horizontal skalieren, vermeidet unnoetige Komplexitaet und haelt die Architektur so lange wie moeglich beherrschbar.

11. FAQ: Vertikale vs. horizontale Skalierung