Apache ShardingSphere 5.5.3: Database Plus über heterogenen Datenbanken
Stärkere Datenintelligenz mit verteiltem SQL für Sharding, Skalierbarkeit und Sicherheit in allen Datenbanken.
Auf einen Blick
- Was ist das?
- ShardingSphere legt eine Erweiterungsschicht über bestehende Datenbanken statt eine neue zu bauen. Wir prüfen die drei Säulen, die beiden Zugangsarten JDBC und Proxy sowie die Abgrenzung zu Vitess.
- Für wen ist es gedacht?
- ShardingSphere passt zu Betrieben, die bestehende Datenbanken behalten und darüber Sharding, Readwrite-Splitting, Verschlüsselung oder Maskierung nachziehen wollen, ohne auf eine neue Datenbank zu wechseln. Weniger geeignet ist es für Teams mit einem kurzen Release-Takt, denn zwischen 5.5.2 und 5.5.3 liegen dreizehn Monate.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Java, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Database Plus: ShardingSphere 5.5.3 über heterogenen Datenbanken
Die README von apache/shardingsphere positioniert das Projekt als Database Plus, also als Normen- und Ökosystemschicht über heterogenen Datenbanken. Der Satz, der die Abgrenzung trägt, lautet: ShardingSphere erzeugt keine neue Datenbank, sondern will die Rechenfähigkeit bestehender Datenbanken erweitern und einen einheitlichen Datenzugang herstellen.
Diese Selbstbeschreibung ist deshalb glaubwürdig, weil sie eine Einschränkung enthält. Ein Werkzeug, das bestehende Datenbanken voraussetzt, muss mit deren Eigenheiten leben, statt sie zu ersetzen.
Zu den Metadaten: Hauptsprache Java, Lizenz Apache-2.0, Standardzweig master, zuletzt gepusht am 28. Februar 2026. GitHub weist 20.790 Sterne, 6.906 Forks und 214 offene Issues aus. Das Projekt wurde am 16. April 2020 ein Top-Level-Projekt der Apache Software Foundation und wird laut README weltweit in über 19.000 Projekten eingesetzt; diese Zahl stützt sich auf eine Suche nach Maven-POM-Dateien und ist selbst berichtet.
Connect, Enhance, Pluggable als drei Säulen von ShardingSphere
Die README benennt drei Säulen. Connect steht für die Anbindung über Datenbankprotokolle, SQL-Dialekte und Speicherformate hinweg, sodass Anwendungen mit unterschiedlichen Datenbanken auf dieselbe Weise sprechen.
Enhance beschreibt den Rechenteil und ist die längste Liste: verteiltes Rechnen mit Datenaufteilung, Readwrite-Splitting und SQL Federation; Datensicherheit mit Verschlüsselung, Maskierung und Audit; Verkehrskontrolle mit Circuit Breaker und Rate Limiting; Beobachtbarkeit mit Monitoring, Tracing und Analyse.
Pluggable meint den Aufbau aus einem Mikrokern mit dreischichtiger Steckarchitektur, die Kern, Funktionsbausteine und Ökosystemanbindung voneinander trennt. Der Vergleich in der README zielt auf Bausteine, die man zusammensetzt. Welche Bausteine im Einzelnen austauschbar sind, führt das verfügbare Material nicht aus.
ShardingSphere-JDBC als JAR im Anwendungsprozess
Der erste Zugang ist ShardingSphere-JDBC, beschrieben als leichtgewichtiges Java-Framework und erweiterter JDBC-Treiber. Die README nennt vier Eigenschaften: direkte Client-Verbindung, bei der sich die Schicht Ressourcen mit der Anwendung teilt; geringer Mehraufwand durch direkte Datenbankverbindung; vollständige Kompatibilität mit ORM-Frameworks wie MyBatis, JPA und Hibernate; sowie keine zusätzliche Bereitstellung, weil das Paket als JAR geliefert wird.
Der Preis dieser Bauart liegt in der Bindung an die Java-Welt. Jede Anwendung bringt die Schicht selbst mit, und eine Änderung an der Sharding-Konfiguration erreicht nur die Anwendungen, die neu gestartet werden.
Als Einsatzfall nennt die README Java-Anwendungen mit hohem Leistungsanspruch, die gemeinsam mit der Geschäftsanwendung betrieben werden. Für Programme in anderen Sprachen ist dieser Weg versperrt.
ShardingSphere-Proxy mit MySQL- und PostgreSQL-Protokoll
Der zweite Zugang ist ShardingSphere-Proxy, ein transparent Datenbank-Proxy mit eigenständiger Bereitstellung. Die README führt dazu einen festen Einstiegspunkt an, der unabhängig von den Anwendungen besteht, Unterstützung für jeden Client, der MySQL oder PostgreSQL spricht, eine Schnittstelle für den Datenbankbetrieb sowie Unternehmensfunktionen wie Cluster-Betrieb, Lastverteilung und Failover.
Damit verschiebt sich die Reichweite: Ein Python-Programm oder ein Shell-Skript kann die Schicht nutzen, ohne dass Java im Spiel ist. Gleichzeitig kommt ein weiteres Betriebsobjekt hinzu, das überwacht und aktualisiert werden muss.
Die README ordnet diesen Zugang bei gemischten Sprachumgebungen und beim Datenbankbetrieb ein. Welche Protokollversionen der Proxy genau spricht und wie sich Failover in der Praxis verhält, steht im Material nicht.
Hybrider Betrieb über dieselbe Registry und die Release-Folge
Beide Zugänge lassen sich laut README mischen. Für die hybride Architektur beschreibt das Projekt eine gemeinsame Konfiguration über dieselbe Registry, sodass JDBC und Proxy dieselben Regeln lesen. Als Vorteile nennt die README Freiheit in der Architektur und die Wahl des passenden Zugangs je Anwendungsfall.
Das klingt nach einer guten Idee und ist in der Betriebspraxis anspruchsvoll, weil zwei Bauteile denselben Stand sehen müssen. Wer hybride fährt, braucht eine klare Zuständigkeit für die Konfiguration in der Registry.
Zur Wartung: Das jüngste Release ist 5.5.3 vom 28. Februar 2026, davor liegen 5.5.2 vom Januar 2025 und 5.5.1 vom Oktober 2024. Zwischen zwei Patch-Releases vergehen damit teils über ein Jahr, was für Sicherheitsfragen eine eigene Beobachtung des Repositorys nötig macht.
Abgrenzung zu Vitess und was die README offenlässt
Die README stellt drei Vergleiche auf: Gegenüber verteilten Datenbanken sei der Ansatz leichter und schütze Bestandsinvestitionen, gegenüber herkömmlicher Middleware biete er mehr Funktionen, gegenüber Cloud-Angeboten erlaube er Mehr-Cloud-Betrieb. Solche Vergleiche stammen vom Projekt selbst und sind als selbst berichtet zu lesen.
Eine unabhängige Alternative ist Vitess. Es stammt aus dem Umfeld von YouTube, gehört zur Cloud Native Computing Foundation und skaliert MySQL horizontal über eine Proxy-Schicht mit eigenen Tabellen-Servern. Der Unterschied liegt im Ansatz: Vitess setzt auf MySQL als Ziel und bringt einen eigenen Betriebsapparat mit, während ShardingSphere als Schicht über beliebigen Datenbanken sitzt und zusätzlich Verschlüsselung, Maskierung und Audit anbietet.
Offen bleibt im Material einiges: Ein Installationsbefehl und konkrete Konfigurationsschlüssel stehen im verfügbaren README-Abschnitt nicht, sie liegen auf shardingsphere.apache.org. Auch Leistungswerte und eine Liste unterstützter Datenbankversionen fehlen. Rechtlich gilt Apache License 2.0.
Redaktionelles Fazit
ShardingSphere passt zu Betrieben, die bestehende Datenbanken behalten und darüber Sharding, Readwrite-Splitting, Verschlüsselung oder Maskierung nachziehen wollen, ohne auf eine neue Datenbank zu wechseln. Weniger geeignet ist es für Teams mit einem kurzen Release-Takt, denn zwischen 5.5.2 und 5.5.3 liegen dreizehn Monate. Vor einer Entscheidung sollte geklärt sein, ob der Zugang über das JAR von ShardingSphere-JDBC oder über ShardingSphere-Proxy mit MySQL- beziehungsweise PostgreSQL-Protokoll erfolgen soll, und eine Konfiguration über die Registry muss in einer Testumgebung stehen.
Community-Notizen