ExtendDB: ejecuta la API de DynamoDB sobre tu propia base de datos

Imagina que el sistema de historiales de un hospital tiene que quedarse dentro del edificio — los datos de los pacientes nunca pueden salir de la red on-prem, un auditor da el visto bueno a cada dependencia, y los portátiles de desarrollo no tienen internet en absoluto. El equipo ya escribió la aplicación contra la API de DynamoDB y le gusta: búsquedas por clave en milisegundos de un solo dígito, un modelo de Items limpio, sin migraciones de schema que cuidar. Pero el DynamoDB gestionado es un servicio en la nube, y "manda los datos a AWS" es inviable aquí.

ExtendDB está construido exactamente para esa brecha. Habla el protocolo de cable de DynamoDB pero almacena los datos en una base de datos que ejecutas tú.

Qué es ExtendDB

ExtendDB es un adaptador de código abierto de AWS — escrito por ingenieros de AWS DynamoDB y anunciado en el AWS Database Blog — que implementa el protocolo de cable DynamoDB JSON en Rust. Como responde a la misma API HTTP que el servicio gestionado, tus AWS SDK existentes y la AWS CLI funcionan sin cambios. Lo único que se mueve es la URL del endpoint — sin reescritura de código, sin nueva librería cliente.

La parte interesante es lo que se sienta detrás de esa API. ExtendDB tiene backends de almacenamiento conectables: PostgreSQL es la implementación de referencia, y se cita Cassandra como otro backend posible. Los nuevos backends se implementan sin modificar el núcleo, de modo que la capa de compatibilidad con DynamoDB y la capa de almacenamiento evolucionan de forma independiente.

Así, una petición fluye de esta manera:

Qué admite — y qué no

Según la documentación de inicio y el anuncio, ExtendDB (v0.1) cubre las operaciones que la mayoría de las aplicaciones realmente llaman:

• Tablas — Create, Delete, Describe, List, Update.
• Items — Put, Get, Delete, Update (incluidas las acciones de actualización SET / REMOVE / ADD / DELETE).
• Query y Scan — condiciones de clave, expresiones de filtro, proyecciones, paginación e índices secundarios.
• Batch — BatchGetItem y BatchWriteItem.
• Transacciones — TransactGetItems y TransactWriteItems.
• Streams, TTL, Import/Export y Tags.

Lo que deliberadamente no implementa es el conjunto de funcionalidades gestionadas específicas de DynamoDB — en particular las Global Tables y la replicación entre regiones. Esas son propiedades de la infraestructura global del servicio gestionado, no de la superficie de la API, así que no se trasladan a un adaptador que alojas tú mismo.

vs DynamoDB Local

Puede que ya uses DynamoDB Local para el desarrollo offline. Eso es un único JAR (o la imagen Docker amazon/dynamodb-local) pensado para pruebas unitarias en una sola máquina. ExtendDB apunta más amplio que esa herramienta de un solo proceso: desarrollo local, despliegues on-prem, entornos edge y aislados de internet, y configuraciones híbridas / multinube donde quieres la API de DynamoDB pero los datos viven en infraestructura que tú controlas.

vs DynamoDB gestionado

Esta es la línea que AWS traza explícitamente, y que importa:

ExtendDB no es DynamoDB. Es una implementación compatible, no un reemplazo del servicio gestionado. Las características de rendimiento, el comportamiento de escalado y las propiedades operativas difieren.

Concretamente, cuando ejecutas ExtendDB:

• Eres el dueño de la disponibilidad y las copias de seguridad de la base de datos. No hay durabilidad multi-AZ gestionada ni recuperación a un punto en el tiempo haciéndolo por ti — eso recae en ti y en tus operaciones de PostgreSQL.
• TLS es obligatorio en el endpoint.
• Las credenciales son de estilo IAM pero separadas de AWS IAM — ExtendDB tiene su propio modelo de credenciales; no se autentica contra tu cuenta de AWS.

Es v0.1 y tiene licencia Apache 2.0. Trátalo como software temprano: genial para los entornos de arriba, no un cambio directo para DynamoDB gestionado a escala de producción.

Configuración

ExtendDB corre en Linux y macOS y necesita Rust 1.85+ y PostgreSQL 14+. El flujo son dos comandos:

extenddb init
extenddb serve

init provisiona el schema en tu base de datos PostgreSQL; serve arranca el servidor del protocolo de cable, que escucha en un endpoint como https://127.0.0.1:8000 (TLS es obligatorio, de ahí https).

Apunta el AWS SDK a él igual que harías con cualquier endpoint personalizado — solo cambian la URL y las credenciales:

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

Todo lo que va más allá de la configuración del cliente — PutItem, Query, TransactWriteItems — es idéntico al código que escribirías contra DynamoDB gestionado. Un diseño de Items de una sola tabla funciona exactamente como lo hace en la nube:

Hazlo en DynoTable

Como ExtendDB habla el protocolo de cable de DynamoDB, no necesitas una herramienta de administración aparte para él — apunta DynoTable al endpoint de ExtendDB de la misma manera que lo conectarías a DynamoDB Local: crea un Profile offline (local) con el puerto de ExtendDB y credenciales desechables, y DynoTable explorará, consultará y editará los Items — solo que ahora están respaldados por PostgreSQL en tu propio disco en lugar del almacén en memoria de un JAR.

Esta es la recompensa de la compatibilidad con el protocolo de cable: el SQL Workbench, el constructor visual de consultas y la edición de Items funcionan todos contra ExtendDB sin cambios, así que obtienes una GUI real sobre tus datos autoalojados sin escribir scripts de scan.

Una advertencia a tener en cuenta: el endpoint de ExtendDB es solo HTTPS, mientras que el Profile offline de DynoTable (como la mayoría de las configuraciones de DynamoDB Local) apunta a un host:port de loopback. Si tu cliente o tu herramienta necesita un listener de loopback en texto plano, termina TLS delante de ExtendDB (o ejecuta un proxy inverso local) y apunta la GUI a eso — el protocolo en el cable sigue siendo DynamoDB JSON de todos modos.

Trampas

• No trates la v0.1 como DynamoDB de producción. El escalado, la latencia y la durabilidad son los de tu PostgreSQL, no los de AWS. Haz benchmarks para tu carga de trabajo antes de depender de ello.
• Sin Global Tables / replicación entre regiones. Si tu diseño depende de activo-activo multirregión, ExtendDB no es el camino — esa es una funcionalidad del servicio gestionado.
• Haz tú mismo las copias de seguridad de la base de datos subyacente. No hay PITR gestionado; un volumen de PostgreSQL borrado se ha ido. Configura pg_dump / archivado de WAL como con cualquier otro PostgreSQL.
• Las credenciales son propias de ExtendDB, no de AWS IAM. No esperes que las políticas, roles o claves de condición de IAM gobiernen el acceso — ese modelo de autorización no se traslada.

Próximos pasos

• Modela primero tus patrones de acceso — la misma disciplina de single-table design aplica tanto si el backend es DynamoDB como PostgreSQL-vía-ExtendDB.
• Construye e inspecciona tus lecturas y escrituras con el DynamoDB Expression Builder, y luego convierte fixtures entre JSON plano y el formato de cable con el conversor DynamoDB-JSON.
• Cuando estés listo para juguetear con una instancia de ExtendDB en vivo, conecta DynoTable y explórala como cualquier otra tabla.