ExtendDB: Wann DynamoDB-Kompatibilität außerhalb von AWS für Teams wirklich sinnvoll ist

ExtendDB ist kein neuer Datenbankdienst, sondern ein DynamoDB-kompatibler Adapter

AWS hat ExtendDB am 20. Mai 2026 als Open-Source-Projekt in Version 0.1 vorgestellt. Der Punkt der Meldung ist nicht, dass AWS eine neue Datenbank gestartet hat. Wichtiger ist: ExtendDB implementiert die DynamoDB-API als Adapter mit austauschbaren Storage-Backends und startet dabei mit PostgreSQL als Referenz-Backend.

Für Teams klingt das zunächst nach Lock-in-Entschärfung. Praktisch ist die Aussage enger: Anwendungen, die heute schon mit DynamoDB-Clients, SDKs und Tools arbeiten, sollen per Endpoint-Wechsel gegen ExtendDB laufen können, ohne dass die Anwendungslogik komplett neu geschrieben werden muss. Genau das macht die Ankündigung für Plattform- und Architekturteils interessant. Es geht weniger um "DynamoDB ersetzen" als um DynamoDB-artige Workloads außerhalb des nativen Managed Service.

Der eigentliche Leserwert liegt deshalb in einer nüchternen Frage: Wann ist API-Kompatibilität wichtiger als die Managed-Eigenschaften von DynamoDB? Wer nur komplett in AWS arbeitet, bekommt laut Projekt-Dokumentation mit nativer DynamoDB meist den einfacheren Weg. Spannend wird ExtendDB erst dort, wo lokale Entwicklung, CI, On-Prem oder getrennte Edge-Umgebungen reale Reibung erzeugen.

Wie ExtendDB die DynamoDB-API auf PostgreSQL und weitere Backends abbilden soll

Technisch sollten Teams ExtendDB als Kompatibilitäts-Layer lesen. AWS beschreibt das Projekt offiziell als Implementierung der DynamoDB-API mit pluggable storage backends. Die Projekt-Dokumentation formuliert es noch klarer: Anwendungen, die bereits DynamoDB-Clients wie AWS SDKs oder Bibliotheken im DynamoDB-Ökosystem nutzen, können unverändert gegen ExtendDB laufen, wenn nur der Endpoint gewechselt wird.

Das hat zwei Folgen. Erstens bleibt das Programmiermodell näherungsweise gleich. Zweitens heißt das noch nicht, dass auch alle Service-Eigenschaften gleich bleiben. Ein Adapter kann API-Semantik nachbilden, aber er macht aus PostgreSQL nicht automatisch den vollen Managed-DynamoDB-Dienst.

Gerade PostgreSQL als Start-Backend ist strategisch klug gewählt. Viele Unternehmen betreiben Postgres bereits, verstehen Backup, Betrieb und Monitoring dafür und können so einen DynamoDB-kompatiblen Layer in bekannte Umgebungen einhängen. Das senkt die Einstiegshürde. Es bedeutet aber nicht, dass unter dem Adapter plötzlich dieselben Betriebs- und Skalierungseigenschaften entstehen wie im nativen AWS-Service.

Für technische Entscheider ist deshalb die saubere Unterscheidung wichtig:

• Code-Portabilität: bestehende Clients und SDKs weiterverwenden
• Betriebsportabilität: Workloads auch außerhalb von AWS ausführen
• Feature-Portabilität: nicht automatisch gegeben

Genau an diesem Punkt scheitern viele vorschnelle "Lock-in gelöst"-Interpretationen.

Warum AWS mit ExtendDB plötzlich auch Entwickler-Laptops, On-Prem und Edge adressiert

Die offiziellen Quellen nennen drei Nutzungsmuster, die für B2B-Teams realistisch sind.

1. Höherwertige lokale Entwicklung
AWS positioniert ExtendDB ausdrücklich für Entwickler-Laptops und spricht von high-fidelity local development. Das ist relevant, weil lokale Entwicklung mit DynamoDB zwar heute schon möglich ist, aber DynamoDB Local laut AWS eigene Unterschiede zum Webservice hat. Für Teams, die stärker an echter API-Semantik, Expressions und Fehlerverhalten testen wollen, kann ExtendDB deshalb attraktiver sein als reine Mocks oder ein sehr vereinfachtes lokales Setup.

2. CI und Integrationstests näher am realen API-Verhalten
Auch für CI nennt AWS ExtendDB explizit. Der Nutzen liegt nicht automatisch in Geschwindigkeit oder Kosten, sondern in geringerer Abweichung zwischen Testumgebung und späterem Produktionsverhalten auf API-Ebene. Gerade bei Teams mit mehreren Services kann das wertvoller sein als ein "läuft schon lokal"-Ansatz.

3. On-Prem- und Edge-Szenarien mit DynamoDB-förmiger API
Hier wird die Meldung strategisch. AWS nennt On-Prem-Rechenzentren und disconnected edge sites als Zielumgebungen. Für Unternehmen mit Datenhoheit, Netztrennung oder bestehenden Datenbankstandards kann ExtendDB damit ein Brückenprodukt werden: Die Anwendung spricht weiter das DynamoDB-Modell, der tatsächliche Speicher läuft aber in einer Umgebung, die das Team selbst betreibt.

Genau in solchen Fällen wird die Frage nicht mehr nur technisch, sondern organisatorisch: Braucht das Team wirklich die AWS-Serviceeigenschaften von DynamoDB – oder vor allem eine stabile API-Oberfläche über mehrere Betriebsumgebungen hinweg?

Wer solche Architekturfragen öfter beurteilen muss, findet eine ähnliche Governance-Perspektive auch in unserem Beitrag MCP für Unternehmen: Wann sich eigene AI-Agent-Integrationen wirklich lohnen.

Weniger Client-Lock-in heißt noch keine Portabilität des gesamten Betriebs

ExtendDB kann den Client-Lock-in reduzieren, weil bestehende DynamoDB-Clients, SDKs und Tools weiterverwendet werden können. Das ist realer Wert. Aber daraus folgt noch keine vollständige Portabilität.

Erstens bleibt das Datenmodell relevant. Wer über Jahre Anwendungslogik, Zugriffsmuster und Betriebsannahmen auf DynamoDB ausgerichtet hat, trägt diese Entscheidungen in vielen Fällen weiter – selbst wenn nun ein anderes Backend darunterliegt.

Zweitens fehlt die Feature-Portabilität. Die ExtendDB-Dokumentation sagt selbst, wann man das Projekt nicht empfehlen sollte: bei komplett in AWS laufenden Anwendungen, bei Bedarf an Global Tables mit MRSC, bei DAX, bei automatischer Skalierung sowie bei Managed Backup und Restore. Genau dort liegt der Unterschied zwischen API-Kompatibilität und Service-Gleichheit.

Drittens verschiebt sich der Schwerpunkt auf Operations. Native DynamoDB Global Tables replizieren Tabellen automatisch über AWS-Regionen hinweg und nutzen weiter die bestehenden DynamoDB-APIs. Bei ExtendDB bekommt das Team dagegen mehr Freiheitsgrade, aber auch mehr eigene Betriebsverantwortung: Datenbankbetrieb, Backup, Recovery, Monitoring und Lastverhalten landen wieder deutlich stärker im eigenen Haus.

Für CTOs und Plattform-Teams ist die saubere Lesart daher: ExtendDB kann Wechselkosten für Clients und Entwicklungs-Workflows senken. Es löst aber nicht automatisch die tieferen Fragen von Architektur, Feature-Abhängigkeit und Betriebsmodell.

Welche DynamoDB-Eigenschaften ExtendDB nicht mitbringt

Die wichtigste Negativabgrenzung kommt ausgerechnet aus der Projekt-Dokumentation selbst – und das erhöht ihre Glaubwürdigkeit. ExtendDB ist laut offizieller Empfehlung nicht die erste Wahl, wenn eine neue Anwendung vollständig in AWS-Regionen laufen soll. In diesem Fall bleibt nativer DynamoDB meist einfacher.

Besonders klar ist die Grenze bei Funktionen, die den Wert des Managed Service ausmachen:

• Global Tables, inklusive Szenarien mit Multi-Region Strong Consistency
• DAX für sehr schnelle In-Memory-Caching-Szenarien
• Auto Scaling
• Managed Backup und Restore
• generell der Charakter einer turnkey managed database

Hinzu kommt der Reifegrad: AWS hat ExtendDB als Version 0.1 angekündigt. Das ist kein Ausschlusskriterium, aber ein deutlicher Hinweis auf frühe Produktreife. Wer daraus sofort einen Produktionsstandard ableitet, liest mehr hinein, als die aktuellen Quellen tragen.

Pilot zuerst dort, wo API-Kompatibilität wichtiger ist als Managed-Komfort

Ein realistischer Einstieg ist deshalb klein und klar abgegrenzt. Sinnvoll sind zuerst Szenarien, in denen der Hauptnutzen tatsächlich aus der API-Kompatibilität kommt:

1. lokale Entwicklung vereinheitlichen
2. CI- und Integrationstests realitätsnäher machen
3. ein begrenztes On-Prem- oder Edge-Szenario evaluieren

Vor einem breiteren Pilot sollten Teams mindestens diese Punkte prüfen:

• Wie hoch ist die tatsächliche API-Kompatibilität für die eigenen Workloads?
• Welche Unterschiede entstehen unter Last, bei Fehlerfällen und im Recovery?
• Wer übernimmt Betrieb, Monitoring, Backup und Restore des Backends?
• Ist das Ziel wirklich Lock-in-Reduktion – oder eher kontrollierter Hybridbetrieb?
• Welche nativen DynamoDB-Features würden im Ernstfall fehlen?

Genau hier trennt sich Architekturgewinn von Zusatzkomplexität. Wer diesen Pilot sauber aufsetzt, vermeidet denselben Denkfehler, den wir auch an anderer Stelle sehen: neues Tooling wird oft mit schnellerer Delivery verwechselt. Mehr dazu in KI-Tempo ist nicht Delivery: Was Entwickler jetzt wirklich brauchen.

Unterm Strich ist ExtendDB ein spannendes Signal von AWS: Das Unternehmen öffnet das DynamoDB-Programmiermodell für Umgebungen, in denen der native Service nicht passt. Für viele Teams bleibt das dennoch eine Nischenentscheidung mit echtem Nutzen, nicht der Beginn eines allgemeinen DynamoDB-Ersatzes.