DynamoDB Local ist seit 2013 der Laptop-Ersatz fur AWS DynamoDB. Es ist ein Java-JAR, lauft im Speicher oder gegen eine SQLite-Datei, akzeptiert fast jede Request-Form, hat keine echte Authentifizierung und behandelt Streams recht locker. Es ist in Ordnung fur Unit-Tests. Es fangt an zu brechen, sobald dein Code mehr als PutItem und GetItem macht.

ExtendDB v0.1.0 wurde gerade veroffentlicht. Es ist eine Clean-Room-Implementierung des DynamoDB-Wire-Protokolls, geschrieben in Rust von AWS-Ingenieuren, unterstutzt durch PostgreSQL, Apache 2.0. Die Ankundigung lautet "DynamoDB Local, aber man kann es ernst nehmen." Dieser Beitrag ist ein praktischer Blick darauf, ob das halt, ausgefuhrt als Side-by-Side-Labor auf einem einzelnen Mac.

Was ExtendDB tatsachlich ist

ExtendDB ist kein Fork von DynamoDB. Es ist kein DynamoDB-Quellcode darin enthalten. Was es tut, ist, das DynamoDB-Wire-Protokoll zu sprechen (den JSON-1.0 X-Amz-Target-Dispatch, den die AWS SDKs verwenden), sodass ein bestehender boto3- oder AWS CLI-Client mit einer Flag-Anderung auf einen ExtendDB-Endpunkt verwiesen werden kann, und es funktioniert, ohne Anderungen.

Unter der Haube ist es ein kleiner, fokussierter Rust-Workspace:

flowchart LR
    bin[extenddb
CLI + daemon] --> server[extenddb-server
HTTP + console]
    server --> engine[extenddb-engine
DynamoDB op handlers]
    server --> auth[extenddb-auth
SigV4 + IAM policy]
    engine --> core[extenddb-core
types, expressions]
    engine --> storage[extenddb-storage
trait definitions]
    storage --> pg[extenddb-storage-postgres
PostgreSQL backend]

Der extenddb-storage-Crate sind nur Trait-Definitionen. extenddb-storage-postgres ist heute die einzige Implementierung. Die Naht ist sauber genug, dass ein anderes Backend (sqlite, foundationdb, was auch immer) hauptsachlich auf die Implementierung der Traits hinauslaufen wurde. Hier ist der Lifecycle-Trait, wortlich aus crates/storage/src/lib.rs:

/// All methods receive `account_id` to scope operations to a single account.
/// This enables multi-account isolation: different accounts can have tables
/// with the same name without conflict.
pub trait TableEngine: Send + Sync {
    fn create_table(
        &self,
        account_id: &str,
        input: CreateTableInput,
    ) -> BoxFuture<'_, Result>;
    fn delete_table(
        &self,
        account_id: &str,
        input: DeleteTableInput,
    ) -> BoxFuture<'_, Result>;
    fn describe_table(
        &self,
        account_id: &str,
        input: DescribeTableInput,
    ) -> BoxFuture<'_, Result>;
    // ...list_tables, update_table, table_key_info
}

[... Der Artikel setzt die detaillierte technische Analyse von ExtendDB gegenuber DynamoDB Local fort, mit Labs zu Baseline-Paritat, CRUD-Operationen, Authentifizierung, Streams, TTL, Multi-Account-Isolation und PostgreSQL-Inspektion ...]

Fazit

Wenn du jemals Testcode geschrieben hast, der DynamoDB Local kaschiert hat (Auth ausgemockt, Streams-Assertions ubersprungen, TTL gestubbet) und dich leise gefragt hast, ob sich der echte Dienst anders verhalten wurde, ist ExtendDB interessant. Es ist der erste lokale DynamoDB-Ersatz, der Auth, Streams, TTL, Multi-Account-Isolation und Haltbarkeit ernst nimmt, und der Storage-Layer ist einfaches Postgres, in das du mit psql reinschauen kannst.

Fur CI-Pipelines, die realistische Auth- und Stream-Semantik benotigen, On-Prem- oder Air-Gapped-Deployments und Dev-Teams, die Zeit mit "nun ja, es funktioniert gegen DynamoDB Local..." verloren haben, ist v0.1.0 bereits ein nutzliches Werkzeug. Fur alles, was von bytegenauer Wire-Kompatibilitat mit dem echten Dienst abhangt, mache zuerst deinen eigenen Durchlauf.

Links: