ExtendDB: das DynamoDB-API auf deiner Datenbank betreiben

Angenommen, ein Krankenhaus-Informationssystem muss im Gebäude bleiben — Patientendaten dürfen das lokale Netz nie verlassen, ein Prüfer gibt jede Abhängigkeit frei, und die Entwicklerlaptops haben überhaupt kein Internet. Das Team hat die Anwendung bereits gegen das DynamoDB-API geschrieben und mag es: Key-Lookups in einstelligen Millisekunden, ein sauberes Item-Modell, keine Schema-Migrationen, die man hüten muss. Aber verwaltetes DynamoDB ist ein Cloud-Dienst, und „schick die Daten zu AWS“ ist hier undenkbar.

ExtendDB ist genau für diese Lücke gebaut. Es spricht das DynamoDB-Wire-Protokoll, speichert die Daten aber in einer Datenbank, die du betreibst.

Was ist ExtendDB?

ExtendDB ist der Open-Source-Adapter von AWS (in Rust geschrieben), der das DynamoDB-JSON-Wire-Protokoll auf einer Datenbank implementiert, die du selbst betreibst, etwa PostgreSQL. Deine bestehenden AWS-SDKs und die AWS CLI arbeiten unverändert weiter — nur die Endpoint-URL wandert —, du bekommst also das DynamoDB-API, ohne Daten an den verwalteten Cloud-Dienst zu schicken.

ExtendDB ist ein Open-Source-Adapter von AWS — geschrieben von AWS-DynamoDB-Ingenieuren und im AWS Database Blog angekündigt —, der das DynamoDB-JSON-Wire-Protokoll in Rust implementiert. Weil es dasselbe HTTP-API beantwortet wie der verwaltete Dienst, arbeiten deine bestehenden AWS-SDKs und die AWS CLI unverändert. Das Einzige, was wandert, ist die Endpoint-URL — kein Code-Rewrite, keine neue Client-Bibliothek.

Interessant ist, was hinter diesem API sitzt. ExtendDB hat austauschbare Storage-Backends: PostgreSQL ist die Referenzimplementierung, und Cassandra wird als weiteres mögliches Backend genannt. Neue Backends werden ohne Änderungen am Kern implementiert, die DynamoDB-Kompatibilitätsschicht und die Storage-Schicht entwickeln sich also unabhängig weiter.

Ein Request fließt damit so:

Was es unterstützt — und was nicht

Laut der Getting-started-Doku und der Ankündigung deckt ExtendDB (v0.1) die Operationen ab, die Anwendungen tatsächlich aufrufen:

• Tabellen — Create, Delete, Describe, List, Update.
• Items — Put, Get, Delete, Update (inklusive der Update-Aktionen SET / REMOVE / ADD / DELETE).
• Query und Scan — Key-Bedingungen, Filter Expressions, Projektionen, Paginierung und Secondary Indexes.
• Batch — BatchGetItem und BatchWriteItem.
• Transaktionen — TransactGetItems und TransactWriteItems.
• Streams, TTL, Import/Export und Tags.

Was es bewusst nicht implementiert, ist die Menge der DynamoDB-spezifischen verwalteten Features — allen voran Global Tables und regionsübergreifende Replikation. Das sind Eigenschaften der globalen Infrastruktur des verwalteten Dienstes, nicht der API-Oberfläche, sie übertragen sich also nicht auf einen Adapter, den du selbst hostest.

vs. DynamoDB Local

Vielleicht nutzt du für die Offline-Entwicklung schon DynamoDB Local. Das ist ein einzelnes JAR (oder das Docker-Image amazon/dynamodb-local), gedacht für Unit-Tests auf einer Maschine. ExtendDB zielt breiter als dieses Ein-Prozess-Werkzeug: lokale Entwicklung, On-Prem-Deployments, Edge- und Air-Gapped-Umgebungen sowie Hybrid-/Multi-Cloud-Setups, in denen du das DynamoDB-API willst, die Daten aber in Infrastruktur liegen, die du kontrollierst.

vs. verwaltetes DynamoDB

Das ist die Linie, die AWS ausdrücklich zieht, und sie ist wichtig:

ExtendDB ist nicht DynamoDB. Es ist eine kompatible Implementierung, kein Ersatz für den verwalteten Dienst. Leistungsmerkmale, Skalierungsverhalten und Betriebseigenschaften unterscheiden sich.

Konkret heißt das, wenn du ExtendDB betreibst:

• Verfügbarkeit und Backups der Datenbank gehören dir. Es gibt keine verwaltete Multi-AZ-Dauerhaftigkeit und keine Point-in-Time Recovery, die das für dich erledigt — das liegt bei dir und deinem PostgreSQL-Betrieb.
• TLS ist am Endpoint Pflicht.
• Credentials sind IAM-ähnlich, aber getrennt von AWS IAM — ExtendDB hat ein eigenes Credential-Modell; es authentifiziert nicht gegen dein AWS-Konto.

Es ist v0.1 und unter Apache 2.0 lizenziert. Behandle es als frühe Software: großartig für die oben genannten Umgebungen, kein direkter Ersatz für verwaltetes DynamoDB im Produktionsmaßstab.

ExtendDB selbst misst weder RCU noch WCU — Kapazität ist die Sache deines PostgreSQL. Treffen dieselben API-Aufrufe verwaltetes DynamoDB in us-east-1 mit On-Demand, kostet ein PutItem über 1 KB 1 WCU und ein GetItem über 4 KB 0,5 RCU letztendlich konsistent. Benchmarke ExtendDB auf Latenz; nutze den Preisrechner, um zu vergleichen, wie die Cloud-Rechnung für dasselbe Zugriffsmuster aussähe.

Einrichtung

ExtendDB läuft auf Linux und macOS und braucht Rust 1.85+ und PostgreSQL 14+. Der Ablauf sind zwei Befehle:

extenddb init
extenddb serve

init legt das Schema in deiner PostgreSQL-Datenbank an; serve startet den Wire-Protokoll-Server, der auf einem Endpoint wie https://127.0.0.1:8000 lauscht (TLS ist Pflicht, daher https).

Richte das AWS SDK darauf so aus, wie du es bei jedem eigenen Endpoint tun würdest — nur URL und Credentials ändern sich:

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({
  endpoint: 'https://127.0.0.1:8000',
  region: 'local',
  credentials: {accessKeyId: '<extenddb-key>', secretAccessKey: '<extenddb-secret>'}
});

Alles jenseits der Client-Konfiguration — PutItem, Query, TransactWriteItems — ist identisch zu dem Code, den du gegen verwaltetes DynamoDB schreiben würdest. Ein Single-Table-Item-Layout funktioniert exakt wie in der Cloud:

In DynoTable umsetzen

Weil ExtendDB das DynamoDB-Wire-Protokoll spricht, brauchst du dafür kein eigenes Admin-Werkzeug — richte DynoTable auf den ExtendDB-Endpoint, genauso wie du es mit DynamoDB Local verbinden würdest: Leg ein Offline-Profil (lokal) mit dem ExtendDB-Port und Wegwerf-Credentials an, und DynoTable durchstöbert, fragt ab und bearbeitet die Items — nur liegen sie jetzt in PostgreSQL auf deiner eigenen Platte statt im In-Memory-Store eines JAR.

Das ist der Gewinn der Wire-Protokoll-Kompatibilität: Der SQL Workbench, der visuelle Query Builder und das Bearbeiten von Items funktionieren unverändert gegen ExtendDB, du bekommst also eine echte GUI über deinen selbst gehosteten Daten, ohne scan-Skripte zu schreiben.

Ein Vorbehalt, den du einplanen solltest: Der Endpoint von ExtendDB ist nur über HTTPS erreichbar, während das Offline-Profil von DynoTable (wie die meisten DynamoDB-Local-Setups) auf ein Loopback-host:port zielt. Braucht dein Client oder Tooling einen Klartext-Loopback-Listener, terminiere TLS vor ExtendDB (oder betreibe einen lokalen Reverse Proxy) und richte die GUI darauf aus — auf der Leitung ist es so oder so DynamoDB-JSON.

Fallstricke

• Behandle v0.1 nicht wie produktives DynamoDB. Skalierung, Latenz und Dauerhaftigkeit gehören deinem PostgreSQL, nicht AWS. Benchmarke für deinen Workload, bevor du dich darauf verlässt.
• Keine Global Tables / regionsübergreifende Replikation. Setzt dein Design auf Multi-Region-Active-Active, ist ExtendDB nicht der Weg — das ist ein Feature des verwalteten Dienstes.
• Sichere die darunterliegende Datenbank selbst. Es gibt kein verwaltetes PITR; ein verlorenes PostgreSQL-Volume ist weg. Richte pg_dump / WAL-Archivierung ein wie bei jedem anderen PostgreSQL.
• Credentials sind ExtendDBs eigene, nicht AWS IAM. Erwarte nicht, dass IAM-Policies, -Rollen oder Condition Keys den Zugriff regeln — dieses Autorisierungsmodell überträgt sich nicht.

Nächste Schritte

• Modelliere zuerst deine Zugriffsmuster — dieselbe Disziplin des Single-Table-Designs gilt, egal ob das Backend DynamoDB oder PostgreSQL-über-ExtendDB ist.
• Baue und inspiziere deine Lese- und Schreibvorgänge mit dem DynamoDB Expression Builder und konvertiere Fixtures dann mit dem DynamoDB-JSON-Konverter zwischen reinem JSON und dem Wire-Format.
• Wenn du bereit bist, eine laufende ExtendDB-Instanz anzustochern, verbinde DynoTable und durchstöbere sie wie jede andere Tabelle.