ExtendDB : faire tourner l'API DynamoDB sur ta propre base de données

Imagine qu'un système d'archives hospitalières doive rester à l'intérieur du bâtiment — les données patients ne peuvent jamais quitter le réseau sur site, un auditeur valide chaque dépendance, et les laptops des devs n'ont aucun accès internet. L'équipe a déjà écrit l'application contre l'API DynamoDB et l'apprécie : des recherches par clé en quelques millisecondes, un modèle d'item propre, aucune migration de schéma à gérer. Mais DynamoDB managé est un service cloud, et « envoyer les données à AWS » est rédhibitoire ici.

ExtendDB est conçu exactement pour ce vide. Il parle le protocole filaire DynamoDB mais stocke les données dans une base de données que toi tu fais tourner.

Ce qu'est ExtendDB

ExtendDB est un adaptateur open-source d'AWS — écrit par des ingénieurs AWS DynamoDB et annoncé sur le blog AWS Database — qui implémente le protocole filaire JSON de DynamoDB en Rust. Comme il répond à la même API HTTP que le service managé, tes AWS SDK existants et l'AWS CLI fonctionnent sans modification. La seule chose qui change, c'est l'URL de l'endpoint — pas de réécriture de code, pas de nouvelle bibliothèque cliente.

La partie intéressante, c'est ce qui se trouve derrière cette API. ExtendDB a des backends de stockage enfichables : PostgreSQL est l'implémentation de référence, et Cassandra est cité comme autre backend possible. De nouveaux backends sont implémentés sans modifier le cœur, donc la couche de compatibilité DynamoDB et la couche de stockage évoluent indépendamment.

Une requête circule donc ainsi :

ton app  ──DynamoDB JSON──▶  ExtendDB (Rust)  ──▶  PostgreSQL
(SDK inchangé)                 protocole filaire        tes données, ton disque

Ce qu'il prend en charge — et ce qu'il ne prend pas

D'après la documentation de démarrage et l'annonce, ExtendDB (v0.1) couvre les opérations que la plupart des applications appellent réellement :

• Tables — Create, Delete, Describe, List, Update.
• Items — Put, Get, Delete, Update (y compris les actions de mise à jour SET / REMOVE / ADD / DELETE).
• Query et Scan — conditions de clé, expressions de filtre, projections, pagination, et index secondaires.
• Batch — BatchGetItem et BatchWriteItem.
• Transactions — TransactGetItems et TransactWriteItems.
• Streams, TTL, Import/Export, et Tags.

Ce qu'il n'implémente délibérément pas, c'est l'ensemble des fonctionnalités managées spécifiques à DynamoDB — notamment les Global Tables et la réplication inter-régions. Ce sont des propriétés de l'infrastructure globale du service managé, pas de la surface d'API, donc elles ne se reportent pas sur un adaptateur que tu héberges toi-même.

vs DynamoDB Local

Tu utilises peut-être déjà DynamoDB Local pour le développement hors ligne. C'est un unique JAR (ou l'image Docker amazon/dynamodb-local) destiné aux tests unitaires sur une seule machine. ExtendDB vise plus large que cet outil mono-processus : développement local, déploiements sur site, environnements edge et air-gapped, et configurations hybrides / multi-cloud où tu veux l'API DynamoDB mais où les données vivent dans une infrastructure que tu contrôles.

vs DynamoDB managé

C'est la ligne qu'AWS trace explicitement, et elle compte :

ExtendDB n'est pas DynamoDB. C'est une implémentation compatible, pas un remplacement du service managé. Les caractéristiques de performance, le comportement de mise à l'échelle et les propriétés opérationnelles diffèrent.

Concrètement, quand tu fais tourner ExtendDB :

• Tu possèdes la disponibilité et les sauvegardes de la base de données. Il n'y a pas de durabilité multi-AZ managée ni de restauration à un instant donné qui le fasse pour toi — c'est à toi et à tes opérations PostgreSQL de le gérer.
• Le TLS est obligatoire sur l'endpoint.
• Les identifiants sont de type IAM mais distincts d'AWS IAM — ExtendDB a son propre modèle d'identifiants ; il ne s'authentifie pas contre ton compte AWS.

C'est de la v0.1 et c'est sous licence Apache 2.0. Traite-le comme un logiciel à ses débuts : excellent pour les environnements ci-dessus, pas un remplacement clé en main pour du DynamoDB managé à l'échelle de la production.

Configuration

ExtendDB tourne sur Linux et macOS et a besoin de Rust 1.85+ et de PostgreSQL 14+. Le flux tient en deux commandes :

extenddb init
extenddb serve

init provisionne le schéma dans ta base de données PostgreSQL ; serve démarre le serveur de protocole filaire, qui écoute sur un endpoint comme https://127.0.0.1:8000 (le TLS est requis, d'où https).

Pointe l'AWS SDK dessus comme tu le ferais pour n'importe quel endpoint personnalisé — seules l'URL et les identifiants changent :

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>'}
});

Tout ce qui vient après la config du client — PutItem, Query, TransactWriteItems — est identique au code que tu écrirais contre DynamoDB managé. Une disposition d'items en single-table fonctionne exactement comme dans le cloud :

Fais-le dans DynoTable

Parce qu'ExtendDB parle le protocole filaire DynamoDB, tu n'as pas besoin d'un outil d'administration séparé pour lui — pointe DynoTable sur l'endpoint ExtendDB de la même façon que tu le connecterais à DynamoDB Local : crée un profil hors ligne (local) avec le port ExtendDB et des identifiants jetables, et DynoTable parcourra, interrogera et modifiera les items — sauf qu'ils sont maintenant appuyés sur PostgreSQL sur ton propre disque au lieu du stockage en mémoire d'un JAR.

C'est tout l'intérêt de la compatibilité au niveau du protocole filaire : le SQL Workbench, le constructeur de requêtes visuel et l'édition d'items fonctionnent tous contre ExtendDB sans modification, donc tu obtiens une vraie GUI au-dessus de tes données auto-hébergées sans écrire de scripts scan.

Un point à prévoir : l'endpoint d'ExtendDB est HTTPS uniquement, alors que le profil hors ligne de DynoTable (comme la plupart des configurations DynamoDB Local) cible un host:port en loopback. Si ton client ou ton outillage a besoin d'un listener loopback en clair, termine le TLS devant ExtendDB (ou fais tourner un reverse proxy local) et pointe la GUI dessus — le protocole sur le fil reste du DynamoDB JSON dans les deux cas.

Pièges

• Ne traite pas la v0.1 comme du DynamoDB de production. La mise à l'échelle, la latence et la durabilité sont celles de ton PostgreSQL, pas celles d'AWS. Fais des benchmarks pour ta charge de travail avant d'en dépendre.
• Pas de Global Tables / réplication inter-régions. Si ta conception repose sur du multi-régions actif-actif, ExtendDB n'est pas la voie — c'est une fonctionnalité du service managé.
• Sauvegarde la base de données sous-jacente toi-même. Il n'y a pas de PITR managé ; un volume PostgreSQL supprimé est perdu. Mets en place pg_dump / l'archivage WAL comme pour n'importe quel autre PostgreSQL.
• Les identifiants sont ceux d'ExtendDB, pas d'AWS IAM. Ne t'attends pas à ce que des politiques IAM, des rôles ou des clés de condition gouvernent l'accès — ce modèle d'autorisation ne se reporte pas.

Étapes suivantes

• Modélise d'abord tes modes d'accès — la même discipline de single-table design s'applique que le backend soit DynamoDB ou PostgreSQL-via-ExtendDB.
• Construis et inspecte tes lectures et écritures avec le DynamoDB Expression Builder, puis convertis des fixtures entre du JSON simple et le format filaire avec le convertisseur DynamoDB-JSON.
• Quand tu es prêt à toucher à une instance ExtendDB en live, connecte DynoTable et parcours-la comme n'importe quelle autre table.