DynamoDB Local est le substitut de bureau pour AWS DynamoDB depuis 2013. C'est un JAR Java, s'execute en memoire ou contre un fichier SQLite, accepte presque toutes les formes de requetes, n'a pas de vraie authentification, et traite les Streams de maniere assez lache. C'est bien pour les tests unitaires. Ca commence a craquer des que votre code fait autre chose que PutItem et GetItem.

ExtendDB v0.1.0 vient de sortir. C'est une implementation propre du protocole wire DynamoDB, ecrite en Rust par des ingenieurs AWS, adossee a PostgreSQL, Apache 2.0. Le pitch est "DynamoDB Local, mais que vous pouvez prendre au serieux." Cet article est un examen pratique pour voir si cela tient la route, execute comme un laboratoire cote-a-cote sur un seul Mac.

Ce qu'est reellement ExtendDB

ExtendDB n'est pas un fork de DynamoDB. Il n'y a pas de code source DynamoDB dedans. Ce qu'il fait, c'est parler le protocole wire DynamoDB (le dispatch JSON-1.0 X-Amz-Target que les SDKs AWS utilisent), de sorte qu'un client boto3 ou AWS CLI existant peut etre pointe vers un endpoint ExtendDB avec un seul changement de flag et ca fonctionne, sans modifications necessaires.

Sous le capot, c'est un petit workspace Rust cible :

flowchart LR
    bin[extenddb CLI + daemon] --> server[extenddb-server HTTP + console]
    server --> engine[extenddb-engine gestionnaires d'operations DynamoDB]
    server --> auth[extenddb-auth SigV4 + politique IAM]
    engine --> core[extenddb-core types, expressions]
    engine --> storage[extenddb-storage definitions de traits]
    storage --> pg[extenddb-storage-postgres backend PostgreSQL]

Le crate extenddb-storage ne contient que des definitions de traits. extenddb-storage-postgres est la seule implementation aujourd'hui. La couture est suffisamment propre pour qu'un backend different (sqlite, foundationdb, peu importe) se resume principalement a implementer les traits.

Configuration du laboratoire

Les deux backends s'executent sur le meme Mac. Postgres 18.4 de Homebrew. ExtendDB compile avec cargo build --release, puis initialise avec extenddb init. TLS est obligatoire. ExtendDB s'execute ensuite avec extenddb serve sur https://127.0.0.1:8000. DynamoDB Local tourne a cote dans Docker sur le port 8001.

Parite de Base : CRUD fonctionne bien

La premiere chose a savoir est que les choses simples fonctionnent. Un PutItem avec tout le zoo de types, meme appel, les deux backends, meme forme de reponse. Dix sondes couvrant CreateTable (avec un GSI), GetItem fortement coherent, Query, Scan, UpdateItem, DeleteItem, BatchWriteItem et TransactWriteItems. Toutes passent contre les deux backends.

La ou ils divergent

L'authentification est reelle, en quelque sorte

Les deux backends rejettent une requete totalement non signee. Le vrai ecart se montre avec un en-tete Authorization bidon mais analysable : ExtendDB verifie la cle d'acces et rejette ; DynamoDB Local ne regarde pas du tout la cle d'acces et accepte.

Des Streams faconnes comme les vrais

ExtendDB partitionne les enregistrements de stream sur 4 shards par hash de cle de partition. Cela correspond a la facon dont le vrai DynamoDB sharde les streams. DynamoDB Local met tout sur un seul shard.

TTL avec de vrais enregistrements REMOVE

ExtendDB execute un balayeur TTL. L'element expire est supprime et la suppression emet un enregistrement de stream avec l'identite de service specifiee. DynamoDB Local ignore toute cette histoire : pas de balayeur du tout.

Isolation multi-comptes qui fonctionne

Deux comptes peuvent avoir une table avec le meme nom et des lignes differentes, sans interferences. DynamoDB Local a exactement un espace de noms.

Vous pouvez regarder a l'interieur

ExtendDB stocke les elements dans PostgreSQL standard. Chaque table DynamoDB correspond a une table Postgres nommee _ddb_<uuid>. Pour la sauvegarde, la restauration, la replication, le debogage, c'est un monde different du fichier opaque en memoire ou SQLite de DynamoDB Local.

Quand NE PAS l'utiliser

  • Pas implemente du tout : Global Tables, DAX, PartiQL, authentification federee SAML/OIDC, destinations de streaming Kinesis.
  • Forme differente : ImportTable/ExportTableToPointInTime vont vers un chemin de systeme de fichiers local au lieu d'un bucket S3.
  • Derive du protocole wire a surveiller : BatchWriteItem omet UnprocessedItems:{} des reponses reussies. Les champs userIdentity utilisent des cles PascalCase.

Verdict

Si vous avez deja ecrit du code de test qui contournait DynamoDB Local (authentification moquee, assertions Streams sautees, TTL stube) et que vous vous inquietiez silencieusement que le vrai service se comporte differemment, ExtendDB est interessant. C'est le premier substitut DynamoDB local qui prend au serieux l'authentification, les Streams, le TTL, l'isolation multi-comptes et la durabilite, et la couche de stockage est du PostgreSQL standard dans lequel vous pouvez faire psql.

Liens :