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

Imagine qu'un système de dossiers hospitaliers doive rester dans les murs — les données patient ne peuvent jamais quitter le réseau sur site, un auditeur valide chaque dépendance, et les portables des développeurs n'ont aucun accès internet. L'équipe a déjà écrit l'application contre l'API DynamoDB et l'apprécie : recherches par clé en un chiffre de millisecondes, un modèle d'items propre, aucune migration de schéma à surveiller. Mais DynamoDB managé est un service cloud, et « envoyer les données à AWS » est ici rédhibitoire.

ExtendDB est conçu précisément pour ce manque. Il parle le protocole filaire DynamoDB mais stocke les données dans une base de données que tu exploites.

Qu'est-ce qu'ExtendDB ?

ExtendDB est l'adaptateur open-source d'AWS (écrit en Rust) qui implémente le protocole filaire DynamoDB JSON par-dessus une base de données que tu exploites toi-même, comme PostgreSQL. Tes AWS SDK existants et l'AWS CLI continuent de fonctionner sans changement — seule l'URL de l'endpoint bouge — si bien que tu obtiens l'API DynamoDB sans envoyer de données au service cloud managé.

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

Le point intéressant 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. Les nouveaux backends sont implémentés sans modifier le cœur, de sorte que la couche de compatibilité DynamoDB et la couche de stockage évoluent indépendamment.

Une requête circule donc ainsi :

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

D'après les docs 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 propres à 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, si bien qu'elles ne se transposent pas à 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 monoprocessus : développement local, déploiements sur site, environnements edge et déconnectés (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 exécutes ExtendDB :

• Tu es responsable de la disponibilité et des sauvegardes de la base. Il n'y a pas de durabilité multi-AZ managée ni de récupération à un instant donné (point-in-time recovery) qui le fasse pour toi — c'est à toi et à tes opérations PostgreSQL.
• 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 sous licence Apache 2.0. Traite-le comme un logiciel précoce : excellent pour les environnements ci-dessus, pas un remplacement direct d'un DynamoDB managé à l'échelle de la production.

ExtendDB lui-même ne compte ni RCU ni WCU — la capacité, c'est le problème de ton PostgreSQL. Quand les mêmes appels d'API atteignent DynamoDB managé en on-demand dans us-east-1, un PutItem de 1 Ko facture 1 WCU et un GetItem de 4 Ko facture 0,5 RCU en cohérence à terme. Mesure ExtendDB pour la latence ; sers-toi du calculateur de tarifs pour comparer ce à quoi ressemblerait la facture cloud pour le même modèle d'accès.

Installation

ExtendDB tourne sous Linux et macOS et nécessite Rust 1.85+ et PostgreSQL 14+. Le flux tient en deux commandes :

extenddb init
extenddb serve

init provisionne le schéma dans ta base 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 après la config du client — PutItem, Query, TransactWriteItems — est identique au code que tu écrirais contre un DynamoDB managé. Une disposition d'items 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'admin séparé pour lui — pointe DynoTable vers 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 éditera les items — sauf qu'ils sont maintenant adossés à PostgreSQL sur ton propre disque au lieu du magasin en mémoire d'un JAR.

C'est là le bénéfice de la compatibilité de protocole filaire : le Workbench SQL, le générateur de requêtes visuel et l'édition d'items fonctionnent tous contre ExtendDB sans changement, si bien que tu obtiens une vraie GUI sur tes données auto-hébergées sans écrire de scripts scan.

Un point à anticiper : l'endpoint d'ExtendDB est HTTPS uniquement, tandis que le profil hors ligne de DynoTable (comme la plupart des configs DynamoDB Local) vise 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 un DynamoDB de production. La mise à l'échelle, la latence et la durabilité sont celles de ton PostgreSQL, pas celles d'AWS. Benchmarke pour ta charge avant d'en dépendre.
• Pas de Global Tables / réplication inter-régions. Si ta conception repose sur du multi-région actif-actif, ExtendDB n'est pas la voie — c'est une fonctionnalité du service managé.
• Sauvegarde toi-même la base sous-jacente. Il n'y a pas de PITR managé ; un volume PostgreSQL supprimé est perdu. Mets en place pg_dump / l'archivage WAL comme pour tout autre PostgreSQL.
• Les identifiants sont ceux d'ExtendDB, pas AWS IAM. N'attends pas que des politiques IAM, des rôles ou des clés de condition gouvernent l'accès — ce modèle d'autorisation ne se transpose 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 les fixtures entre JSON brut et format filaire avec le convertisseur DynamoDB-JSON.
• Quand tu es prêt à tâter d'une instance ExtendDB en direct, connecte DynoTable et parcours-la comme n'importe quelle autre table.