ExtendDB: esegui l'API DynamoDB sul tuo database

Immagina che il sistema di cartelle cliniche di un ospedale debba restare dentro l'edificio — i dati dei pazienti non possono mai lasciare la rete on-prem, un auditor approva ogni dipendenza, e i laptop degli sviluppatori non hanno alcun accesso a internet. Il team ha già scritto l'applicazione contro l'API DynamoDB e gli piace: lookup per chiave in millisecondi a singola cifra, un modello di Item pulito, nessuna migrazione di schema da accudire. Ma il DynamoDB gestito è un servizio cloud, e "mandare i dati ad AWS" qui è inaccettabile.

ExtendDB è costruito esattamente per quel divario. Parla il wire protocol di DynamoDB ma memorizza i dati in un database che gestisci tu.

Cos'è ExtendDB

ExtendDB è un adapter open-source di AWS — scritto dagli ingegneri DynamoDB di AWS e annunciato sull'AWS Database Blog — che implementa il wire protocol DynamoDB JSON in Rust. Poiché risponde alla stessa API HTTP del servizio gestito, i tuoi AWS SDK esistenti e la AWS CLI funzionano invariati. L'unica cosa che cambia è l'URL dell'endpoint — nessuna riscrittura di codice, nessuna nuova client library.

La parte interessante è ciò che sta dietro quell'API. ExtendDB ha backend di storage pluggable: PostgreSQL è l'implementazione di riferimento, e Cassandra è citato come un altro possibile backend. I nuovi backend sono implementati senza modificare il core, così il layer di compatibilità DynamoDB e il layer di storage evolvono in modo indipendente.

Quindi una richiesta fluisce così:

Cosa supporta — e cosa no

Secondo i getting-started docs e l'annuncio, ExtendDB (v0.1) copre le operazioni che la maggior parte delle applicazioni chiama davvero:

• Tabelle — Create, Delete, Describe, List, Update.
• Item — Put, Get, Delete, Update (incluse le update action SET / REMOVE / ADD / DELETE).
• Query e Scan — key condition, filter expression, projection, paginazione e Index secondari.
• Batch — BatchGetItem e BatchWriteItem.
• Transazioni — TransactGetItems e TransactWriteItems.
• Streams, TTL, Import/Export e Tag.

Ciò che deliberatamente non implementa è l'insieme delle feature gestite specifiche di DynamoDB — in particolare Global Tables e la replica cross-Region. Quelle sono proprietà dell'infrastruttura globale del servizio gestito, non della superficie API, quindi non si trasferiscono a un adapter che ospiti tu stesso.

vs DynamoDB Local

Forse usi già DynamoDB Local per lo sviluppo offline. Quello è un singolo JAR (o l'immagine Docker amazon/dynamodb-local) pensato per unit test su una sola macchina. ExtendDB punta più in largo di quello strumento a singolo processo: sviluppo locale, deployment on-prem, ambienti edge e air-gapped, e setup ibridi / multi-cloud dove vuoi l'API DynamoDB ma i dati vivono in infrastruttura che controlli tu.

vs DynamoDB gestito

Questa è la linea che AWS traccia esplicitamente, e conta:

ExtendDB non è DynamoDB. È un'implementazione compatibile, non un sostituto del servizio gestito. Le caratteristiche di prestazione, il comportamento di scaling e le proprietà operative differiscono.

In concreto, quando esegui ExtendDB:

• Possiedi la disponibilità e i backup del database. Non c'è durabilità multi-AZ gestita né point-in-time recovery a farlo per te — quello è a carico tuo e delle tue operazioni PostgreSQL.
• Il TLS è obbligatorio sull'endpoint.
• Le credenziali sono IAM-like ma separate da AWS IAM — ExtendDB ha il suo modello di credenziali; non si autentica contro il tuo account AWS.

È v0.1 e licenziato Apache 2.0. Trattalo come software ancora acerbo: ottimo per gli ambienti sopra, non uno swap drop-in per DynamoDB gestito a scala di produzione.

Configurazione

ExtendDB gira su Linux e macOS e richiede Rust 1.85+ e PostgreSQL 14+. Il flusso è di due comandi:

extenddb init
extenddb serve

init provvede lo schema nel tuo database PostgreSQL; serve avvia il server wire-protocol, che ascolta su un endpoint come https://127.0.0.1:8000 (il TLS è richiesto, da cui https).

Punta l'AWS SDK su di esso come faresti per qualsiasi endpoint custom — cambiano solo l'URL e le credenziali:

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

Tutto ciò che viene dopo la configurazione del client — PutItem, Query, TransactWriteItems — è identico al codice che scriveresti contro DynamoDB gestito. Un layout di Item single-table funziona esattamente come nel cloud:

Fallo in DynoTable

Poiché ExtendDB parla il wire protocol di DynamoDB, non ti serve uno strumento di amministrazione separato — punta DynoTable sull'endpoint ExtendDB allo stesso modo in cui lo collegheresti a DynamoDB Local: crea un profilo offline (locale) con la porta di ExtendDB e credenziali usa-e-getta, e DynoTable sfoglierà, farà query e modificherà gli Item — solo che ora sono supportati da PostgreSQL sul tuo disco invece che dallo store in-memory di un JAR.

Questo è il guadagno della compatibilità wire-protocol: la SQL Workbench, il query builder visuale e l'editing degli Item funzionano tutti contro ExtendDB invariati, così ottieni una vera GUI sui tuoi dati self-hosted senza scrivere script di scan.

Un'avvertenza da prevedere: l'endpoint di ExtendDB è solo HTTPS, mentre il profilo offline di DynoTable (come la maggior parte dei setup DynamoDB-Local) punta a un host:port di loopback. Se il tuo client o tooling ha bisogno di un listener di loopback in chiaro, termina il TLS davanti a ExtendDB (o esegui un reverse proxy locale) e punta la GUI su quello — il protocollo sul filo resta comunque DynamoDB JSON.

Trappole

• Non trattare la v0.1 come DynamoDB di produzione. Scaling, latenza e durabilità sono del tuo PostgreSQL, non di AWS. Fai benchmark per il tuo workload prima di dipenderne.
• Niente Global Tables / replica cross-Region. Se il tuo design fa affidamento su multi-Region active-active, ExtendDB non è la strada — quella è una feature del servizio gestito.
• Fai i backup del database sottostante da solo. Non c'è PITR gestito; un volume PostgreSQL droppato è perso. Configura pg_dump / WAL archiving come per qualsiasi altro PostgreSQL.
• Le credenziali sono di ExtendDB, non AWS IAM. Non aspettarti che policy, ruoli o condition key IAM governino l'accesso — quel modello di autorizzazione non si trasferisce.

Prossimi passi

• Modella prima i tuoi access pattern — la stessa disciplina di single-table design si applica che il backend sia DynamoDB o PostgreSQL-via-ExtendDB.
• Costruisci e ispeziona le tue letture e scritture con il DynamoDB Expression Builder, poi converti le fixture tra JSON semplice e il formato wire con il DynamoDB JSON Converter.
• Quando sei pronto a mettere mano a un'istanza ExtendDB live, collega DynoTable e sfogliala come qualsiasi altra tabella.