ExtendDB: Die DynamoDB-API auf deiner eigenen Datenbank betreiben

Sagen wir, ein Krankenhaus-Aktensystem muss innerhalb des Gebäudes bleiben — Patientendaten dürfen niemals das On-Prem-Netzwerk verlassen, ein Prüfer zeichnet jede Abhängigkeit ab, und die Entwickler-Laptops haben überhaupt kein Internet. Das Team hat die Anwendung bereits gegen die DynamoDB-API geschrieben und mag sie: einstellige Millisekunden-Key-Lookups, ein sauberes Item-Modell, keine Schema-Migrationen zu hüten. Aber managed DynamoDB ist ein Cloud-Dienst, und „die Daten an AWS senden" ist hier ein No-Go.

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 ExtendDB ist

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

Der interessante Teil ist, was hinter dieser API sitzt. ExtendDB hat austauschbare Storage-Backends: PostgreSQL ist die Referenzimplementierung, und Cassandra wird als weiteres mögliches Backend genannt. Neue Backends werden implementiert, ohne den Kern zu modifizieren, sodass sich die DynamoDB-Kompatibilitätsschicht und die Storage-Schicht unabhängig voneinander weiterentwickeln.

Eine Anfrage fließt also so:

Was es unterstützt — und was nicht

Laut den Getting-Started-Docs und der Ankündigung deckt ExtendDB (v0.1) die Operationen ab, die die meisten 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-Conditions, Filter-Expressions, Projections, Pagination und Secondary Indexes.
• Batch — BatchGetItem und BatchWriteItem.
• Transaktionen — TransactGetItems und TransactWriteItems.
• Streams, TTL, Import/Export und Tags.

Was es bewusst nicht implementiert, ist der Satz an DynamoDB-spezifischen managed Features — allen voran Global Tables und Cross-Region-Replikation. Das sind Eigenschaften der globalen Infrastruktur des managed Dienstes, nicht der API-Oberfläche, also tragen sie sich nicht auf einen Adapter über, den du selbst hostest.

vs. DynamoDB Local

Vielleicht nutzt du bereits DynamoDB Local für die Offline-Entwicklung. 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 Single-Process-Tool: lokale Entwicklung, On-Prem-Deployments, Edge- und Air-Gapped-Umgebungen sowie Hybrid-/Multi-Cloud-Setups, in denen du die DynamoDB-API willst, die Daten aber in einer Infrastruktur liegen, die du kontrollierst.

vs. managed DynamoDB

Das ist die Linie, die AWS explizit zieht, und sie ist wichtig:

ExtendDB ist nicht DynamoDB. Es ist eine kompatible Implementierung, kein Ersatz für den managed Dienst. Performance-Eigenschaften, Skalierungsverhalten und operative Eigenschaften unterscheiden sich.

Konkret, wenn du ExtendDB betreibst:

• Du verantwortest Verfügbarkeit und Backups der Datenbank. Es gibt keine managed Multi-AZ-Dauerhaftigkeit oder Point-in-Time Recovery, die es für dich erledigt — das liegt an dir und deinem PostgreSQL-Betrieb.
• TLS ist verpflichtend am Endpoint.
• Credentials sind IAM-ähnlich, aber getrennt von AWS IAM — ExtendDB hat sein eigenes Credential-Modell; es authentifiziert sich nicht gegen deinen AWS-Account.

Es ist v0.1 und unter Apache 2.0 lizenziert. Behandle es als frühe Software: großartig für die obigen Umgebungen, kein Drop-in-Ersatz für managed DynamoDB im Produktionsmaßstab.

Setup

ExtendDB läuft auf Linux und macOS und braucht Rust 1.85+ und PostgreSQL 14+. Der Ablauf besteht aus zwei Befehlen:

extenddb init
extenddb serve

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

Richte das AWS-SDK genauso darauf aus, wie du es bei jedem anderen Custom-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 nach der Client-Konfiguration — PutItem, Query, TransactWriteItems — ist identisch mit dem Code, den du gegen managed DynamoDB schreiben würdest. Ein Single-Table-Item-Layout funktioniert genau wie in der Cloud:

In DynoTable umsetzen

Weil ExtendDB das DynamoDB-Wire-Protokoll spricht, brauchst du kein separates Admin-Tool dafür — richte DynoTable auf den ExtendDB-Endpoint genauso aus, wie du es mit DynamoDB Local verbinden würdest: erstelle ein Offline-Profil (local) mit dem ExtendDB-Port und Wegwerf-Credentials, und DynoTable durchsucht, querycht und bearbeitet die Items — nur dass sie jetzt von PostgreSQL auf deiner eigenen Disk gestützt werden statt vom In-Memory-Store eines JAR.

Das ist der Lohn der Wire-Protokoll-Kompatibilität: die SQL Workbench, der visuelle Query-Builder und das Item-Editing funktionieren alle unverändert gegen ExtendDB, sodass du eine echte GUI über deine selbstgehosteten Daten bekommst, ohne scan-Skripte zu schreiben.

Ein Vorbehalt, den du einplanen solltest: ExtendDBs Endpoint ist nur HTTPS, während DynoTables Offline-Profil (wie die meisten DynamoDB-Local-Setups) auf ein Loopback-host:port zielt. Wenn dein Client oder Tooling einen Klartext-Loopback-Listener braucht, terminiere TLS vor ExtendDB (oder betreibe einen lokalen Reverse-Proxy) und richte die GUI darauf aus — das Protokoll auf der Leitung ist in beiden Fällen weiterhin DynamoDB-JSON.

Fallstricke

• Behandle v0.1 nicht als Produktions-DynamoDB. Skalierung, Latenz und Dauerhaftigkeit sind die deines PostgreSQL, nicht die von AWS. Benchmarke für deine Last, bevor du dich darauf verlässt.
• Keine Global Tables / Cross-Region-Replikation. Wenn dein Design auf Multi-Region-Active-Active baut, ist ExtendDB nicht der Weg — das ist ein Feature des managed Dienstes.
• Sichere die zugrunde liegende Datenbank selbst. Es gibt kein managed 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 steuern — dieses Autorisierungsmodell trägt sich nicht über.

Nächste Schritte

• Modelliere zuerst deine Zugriffsmuster — dieselbe Single-Table-Design-Disziplin gilt, ob das Backend DynamoDB oder PostgreSQL-über-ExtendDB ist.
• Baue und inspiziere deine Lese- und Schreibvorgänge mit dem DynamoDB Expression Builder, und konvertiere dann Fixtures zwischen reinem JSON und dem Wire-Format mit dem DynamoDB-JSON-Konverter.
• Wenn du bereit bist, an einer Live-ExtendDB-Instanz zu stochern, verbinde DynoTable und durchsuche sie wie jede andere Tabelle.