Tabellen-Partitionierung vs. Sharding: der oft verwechselte Unterschied

1. Warum beide Begriffe ständig durcheinandergeworfen werden

Beide Konzepte teilen eine große Datenmenge in kleinere Teile auf, um Performance und Wartbarkeit zu verbessern, und beide nutzen dafür oft ein ähnliches Kriterium wie einen Datumsbereich, einen Hash-Wert oder eine Mandanten-ID. Diese oberflächliche Aehnlichkeit führt dazu, dass in Meetings und sogar in Fachartikeln die Begriffe austauschbar verwendet werden, obwohl die Konsequenzen für Architektur, Betriebsaufwand und Konsistenzgarantien fundamental unterschiedlich sind.

Der entscheidende Unterschied liegt in der Ebene, auf der die Aufteilung stattfindet: Partitionierung bleibt vollständig innerhalb einer Datenbankinstanz und ist für Anwendungscode transparent, Sharding verteilt Daten über mehrere physisch getrennte Instanzen und erfordert fast immer Anpassungen in der Anwendungslogik oder einer vorgeschalteten Routing-Schicht.

2. Partitionierung: ein Storage-Feature innerhalb einer einzigen Instanz

Partitionierung ist eine Funktion der Speicher-Engine, die eine logisch einzelne Tabelle intern in mehrere physische Segmente aufteilt, die sogenannten Partitionen. Für die Anwendung und für SQL-Abfragen bleibt die Tabelle ein einziges Objekt mit einem einzigen Namen, einem einzigen Schema und einer einzigen Verbindung. Der Optimizer entscheidet anhand des Partitionierungsschlüssels selbstständig, welche Partitionen für eine gegebene Abfrage überhaupt gelesen werden müssen, ein Vorgang namens Partition Pruning.

Weil alle Partitionen auf demselben Datenbankserver liegen, gelten weiterhin dieselben Transaktions-, Konsistenz- und Isolationsgarantien wie für eine unpartitionierte Tabelle. Ein Join über partitionierte und unpartitionierte Tabellen innerhalb einer Transaktion funktioniert genauso wie gewohnt, ohne dass die Anwendung überhaupt wissen muss, dass die Tabelle intern aufgeteilt ist.

-- Range-Partitionierung nach Datum für Archivierung
CREATE TABLE order_events (
    event_id    BIGINT NOT NULL,
    order_id    BIGINT NOT NULL,
    event_type  VARCHAR(40) NOT NULL,
    created_at  DATE NOT NULL,
    payload     TEXT
) PARTITION BY RANGE (YEAR(created_at)) (
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p2025 VALUES LESS THAN (2026),
    PARTITION p2026 VALUES LESS THAN (2027),
    PARTITION pmax  VALUES LESS THAN MAXVALUE
);

-- Diese Abfrage liest dank Partition Pruning nur p2026
SELECT * FROM order_events
WHERE created_at >= '2026-01-01' AND created_at < '2026-07-01';

3. Sharding: Verteilung über mehrere unabhängige Datenbankinstanzen

Sharding verteilt Daten dagegen auf mehrere physisch und meist auch logisch getrennte Datenbankinstanzen, sogenannte Shards, die jeweils eigene Ressourcen, eigene Verbindungen und in vielen Fällen sogar eigene Server oder Container besitzen. Welcher Shard für welchen Datensatz zuständig ist, entscheidet ein Sharding-Schlüssel, oft in Kombination mit einer Routing-Schicht, die Anfragen an den zuständigen Shard weiterleitet.

Die entscheidende Konsequenz: Ein Join oder eine Transaktion, die Daten aus zwei verschiedenen Shards zusammenführen muss, funktioniert nicht mehr nativ innerhalb eines einzigen SQL-Statements, sondern erfordert entweder eine Anwendung, die selbst mehrere Verbindungen orchestriert, oder eine dedizierte Middleware-Schicht mit eigenen, meist schwächeren Konsistenzgarantien als eine lokale Transaktion.

4. Wann Partitionierung allein das Problem bereits vollständig löst

Partitionierung reicht aus, solange die Gesamtdatenmenge und der Durchsatz auf einer einzigen Datenbankinstanz technisch beherrschbar bleiben, das eigentliche Problem aber in der Verwaltung sehr großer Tabellen liegt: langsame Wartungsoperationen, ineffiziente Löschung alter Daten, oder Abfragen, die durch fehlendes Partition Pruning unnötig viele Zeilen scannen. In all diesen Fällen löst Partitionierung das Problem, ohne dass Anwendungscode, Verbindungslogik oder Transaktionsverhalten sich ändern müssen.

Ein klassisches Beispiel ist eine Ereignistabelle mit täglich wachsendem Datenvolumen, bei der ältere Daten nach einer festen Aufbewahrungsfrist archiviert oder gelöscht werden sollen. Mit Range-Partitionierung nach Datum lässt sich eine komplette alte Partition in Sekunden entfernen, statt Millionen Zeilen einzeln per DELETE zu löschen, was massive Transaktionslogs und lang laufende Locks verursachen würde.

-- Archivierung: alte Partition in Sekunden entfernen statt DELETE über Millionen Zeilen
ALTER TABLE order_events DROP PARTITION p2024;

-- Statt einer langsamen, transaktionslastigen Löschung:
-- DELETE FROM order_events WHERE created_at < '2025-01-01';
-- (kann bei Millionen Zeilen Stunden dauern und den Redo/Undo-Log fluten)

5. Partition Pruning im Ausführungsplan konkret verifizieren

Eine partitionierte Tabelle bringt nur dann einen Performance-Gewinn, wenn der Optimizer bei einer konkreten Abfrage tatsächlich Partition Pruning anwendet, also nicht partitionsrelevante Partitionen von vornherein ausschließt. Ob das geschieht, lässt sich im Ausführungsplan prüfen: Dort wird typischerweise ausgewiesen, wie viele Partitionen insgesamt existieren und wie viele davon für die konkrete Abfrage tatsächlich gelesen wurden.

Ein häufiger Stolperstein ist eine Filterbedingung, die den Partitionierungsschlüssel nur indirekt referenziert, etwa über eine Funktion oder eine implizite Typumwandlung. In solchen Fällen kann der Optimizer den Zusammenhang zwischen Filter und Partitionsgrenze nicht mehr erkennen und liest im schlechtesten Fall wieder alle Partitionen, obwohl die Tabelle korrekt partitioniert ist. Ein Blick in den Plan deckt dieses stille Performance-Problem zuverlässig auf, bevor es im Betrieb überhaupt auffällt.

-- Pruning-Verhalten im Plan prüfen (Syntax exemplarisch)
EXPLAIN
SELECT * FROM order_events
WHERE created_at >= '2026-01-01' AND created_at < '2026-07-01';
-- Plan sollte "partitions: p2026" statt aller vier Partitionen zeigen

-- Stolperfalle: Funktion auf dem Partitionierungsschlüssel
-- verhindert Pruning, da der Optimizer den Wertebereich nicht mehr ableiten kann
SELECT * FROM order_events
WHERE YEAR(created_at) = 2026;

6. Wann tatsächlich Sharding nötig wird

Sharding wird erst dann zur echten Notwendigkeit, wenn die Grenzen einer einzelnen Instanz erreicht sind, unabhängig davon, wie gut die Tabellen partitioniert sind: Der Schreibdurchsatz übersteigt, was ein einzelner Primary-Server verarbeiten kann, die Gesamtdatenmenge sprengt den verfügbaren Speicher oder die realistische Backup-Fenster-Dauer, oder regulatorische Anforderungen verlangen eine geografische Trennung der Daten auf unterschiedliche Regionen mit jeweils eigener Instanz.

In diesen Fällen hilft Partitionierung nicht weiter, weil das Problem nicht die interne Organisation einer Tabelle ist, sondern die begrenzte Kapazität einer einzelnen Maschine oder eines einzelnen Prozesses. Sharding löst dieses Kapazitätsproblem, erkauft sich das aber mit erheblich höherer Komplexität bei Joins, Transaktionen, Schema-Migrationen und Betrieb, weil jede dieser Operationen nun über mehrere unabhängige Instanzen hinweg koordiniert werden muss.

7. Beide Ansätze lassen sich kombinieren, lösen aber unterschiedliche Ebenen

In der Praxis schließen sich Partitionierung und Sharding nicht aus, sondern ergänzen sich: Jeder einzelne Shard kann intern wiederum partitioniert sein, sodass innerhalb eines Shards weiterhin von Partition Pruning und effizienter Archivierung profitiert wird, während Sharding die Kapazitätsgrenze der einzelnen Instanz auflöst. Diese zweistufige Aufteilung ist bei sehr großen, verteilten Systemen der Normalfall.

Wichtig ist dabei, die Aufteilungsschlüssel bewusst zu wählen: Der Sharding-Schlüssel bestimmt, wie Daten über Instanzen verteilt werden, meist nach Mandant oder einem Hash-Wert, während der Partitionierungsschlüssel innerhalb eines Shards oft ein anderes Kriterium wie ein Datum nutzt. Werden beide Schlüssel identisch gewählt, ohne die jeweilige Zielsetzung zu berücksichtigen, entstehen häufig ungleich ausgelastete Shards oder Partitionen mit stark unterschiedlicher Größe.

8. Betriebsaufwand im Vergleich: Transparenz gegen Verteilungskomplexität

Partitionierung erfordert kaum Änderungen am Anwendungscode und lässt sich meist nachträglich auf eine bestehende Tabelle anwenden, ohne dass Verbindungs-Pooling, Fehlerbehandlung oder Monitoring angepasst werden müssen. Backups, Replikation und Hochverfügbarkeit funktionieren weiterhin genauso wie bei einer unpartitionierten Datenbank, weil es sich weiterhin um eine einzige logische Instanz handelt.

Sharding dagegen verlangt eine grundlegend andere Betriebsstrategie: Jeder Shard braucht eigenes Monitoring, eigene Backups, eigene Failover-Strategie, und Schema-Änderungen müssen über alle Shards hinweg koordiniert und synchron ausgerollt werden. Auch Resharding, also die nachträgliche Umverteilung von Daten bei ungleich gewachsenen Shards, ist ein aufwendiger, oft nicht vollständig automatisierbarer Prozess, der bei Partitionierung in dieser Form gar nicht existiert.

9. Entscheidungskriterien für die Wahl des richtigen Ansatzes

Die zentrale Frage lautet nicht, welcher Ansatz moderner oder skalierbarer klingt, sondern welches konkrete Problem vorliegt: Geht es um Wartbarkeit, Abfrage-Performance oder Archivierung einer wachsenden Tabelle, ist Partitionierung fast immer die richtige, deutlich einfachere Antwort. Geht es dagegen um die tatsächliche Kapazitätsgrenze einer einzelnen Datenbankinstanz bei Schreibdurchsatz, Speicherplatz oder geografischer Verteilung, führt an Sharding kein Weg vorbei.

Ein häufiger Fehler ist, Sharding vorsorglich einzuführen, bevor die Kapazitätsgrenzen einer partitionierten Einzelinstanz tatsächlich erreicht sind. Der zusätzliche Betriebsaufwand und die verlorene Transaktionsgarantie über Shard-Grenzen hinweg wiegen in diesen Fällen schwerer als der theoretische Skalierungsgewinn, der oft erst Jahre später tatsächlich benötigt wird.

10. Zusammenfassung

11. FAQ: Partitionierung vs. Sharding: Das Wichtigste auf einen Blick