ExtendDB: Rode a API do DynamoDB no Seu Próprio Banco de Dados

Digamos que um sistema de registros de um hospital precisa permanecer dentro do prédio — os dados dos pacientes nunca podem deixar a rede on-prem, um auditor aprova cada dependência, e os laptops de desenvolvimento não têm internet alguma. O time já escreveu a aplicação contra a API do DynamoDB e gosta dela: buscas por chave em milissegundos de um dígito, um modelo de item limpo, sem migrações de schema para babá. Mas o DynamoDB gerenciado é um serviço de nuvem, e "enviar os dados para a AWS" é inviável aqui.

O ExtendDB foi feito exatamente para essa lacuna. Ele fala o protocolo de transporte do DynamoDB, mas armazena os dados em um banco de dados que você roda.

O que é o ExtendDB

O ExtendDB é um adaptador open-source da AWS — escrito por engenheiros do DynamoDB da AWS e anunciado no AWS Database Blog — que implementa o protocolo de transporte DynamoDB JSON em Rust. Como ele responde à mesma API HTTP que o serviço gerenciado, seus SDKs da AWS existentes e a AWS CLI funcionam sem alteração. A única coisa que muda é a URL do endpoint — sem reescrita de código, sem nova biblioteca de cliente.

A parte interessante é o que fica atrás dessa API. O ExtendDB tem backends de armazenamento plugáveis: o PostgreSQL é a implementação de referência, e o Cassandra é citado como outro backend possível. Novos backends são implementados sem modificar o núcleo, então a camada de compatibilidade com o DynamoDB e a camada de armazenamento evoluem de forma independente.

Então uma requisição flui assim:

O que ele suporta — e o que não suporta

Segundo a documentação de primeiros passos e o anúncio, o ExtendDB (v0.1) cobre as operações que a maioria das aplicações de fato chama:

• Tabelas — Create, Delete, Describe, List, Update.
• Itens — Put, Get, Delete, Update (incluindo as ações de update SET / REMOVE / ADD / DELETE).
• Query e Scan — condições de chave, filter expressions, projeções, paginação e índices secundários.
• Batch — BatchGetItem e BatchWriteItem.
• Transações — TransactGetItems e TransactWriteItems.
• Streams, TTL, Import/Export e Tags.

O que ele deliberadamente não implementa é o conjunto de recursos gerenciados específicos do DynamoDB — mais notavelmente as Global Tables e a replicação entre regiões. Esses são propriedades da infraestrutura global do serviço gerenciado, não da superfície da API, então não se transferem para um adaptador que você hospeda você mesmo.

vs DynamoDB Local

Você talvez já use o DynamoDB Local para desenvolvimento offline. Isso é um único JAR (ou a imagem Docker amazon/dynamodb-local) pensado para testes unitários em uma máquina. O ExtendDB mira mais amplo do que essa ferramenta de processo único: desenvolvimento local, deployments on-prem, ambientes de edge e air-gapped, e setups híbridos / multi-cloud onde você quer a API do DynamoDB mas os dados vivem em infraestrutura que você controla.

vs DynamoDB gerenciado

Essa é a linha que a AWS traça explicitamente, e ela importa:

O ExtendDB não é o DynamoDB. É uma implementação compatível, não um substituto para o serviço gerenciado. As características de desempenho, o comportamento de escalabilidade e as propriedades operacionais diferem.

Concretamente, quando você roda o ExtendDB:

• Você é dono da disponibilidade e dos backups do banco de dados. Não há durabilidade multi-AZ gerenciada nem point-in-time recovery fazendo isso por você — isso fica por sua conta e da sua operação do PostgreSQL.
• O TLS é obrigatório no endpoint.
• As credenciais são parecidas com IAM, mas separadas do AWS IAM — o ExtendDB tem o seu próprio modelo de credenciais; ele não autentica contra a sua conta AWS.

É v0.1 e licenciado sob Apache 2.0. Trate-o como software inicial: ótimo para os ambientes acima, não uma troca direta para o DynamoDB gerenciado em escala de produção.

Configuração

O ExtendDB roda em Linux e macOS e precisa de Rust 1.85+ e PostgreSQL 14+. O fluxo é de dois comandos:

extenddb init
extenddb serve

O init provisiona o schema no seu banco PostgreSQL; o serve inicia o servidor de protocolo, que escuta em um endpoint como https://127.0.0.1:8000 (o TLS é obrigatório, daí o https).

Aponte o SDK da AWS para ele do mesmo jeito que faria com qualquer endpoint customizado — apenas a URL e as credenciais mudam:

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

Tudo depois da configuração do cliente — PutItem, Query, TransactWriteItems — é idêntico ao código que você escreveria contra o DynamoDB gerenciado. Um layout de item single-table funciona exatamente como funciona na nuvem:

Faça no DynoTable

Como o ExtendDB fala o protocolo de transporte do DynamoDB, você não precisa de uma ferramenta de administração separada para ele — aponte o DynoTable para o endpoint do ExtendDB do mesmo jeito que você o conectaria ao DynamoDB Local: crie um perfil offline (local) com a porta do ExtendDB e credenciais descartáveis, e o DynoTable vai navegar, consultar e editar os itens — exceto que agora eles são respaldados pelo PostgreSQL no seu próprio disco em vez do armazenamento em memória de um JAR.

Essa é a recompensa da compatibilidade com o protocolo de transporte: o SQL Workbench, o construtor visual de consultas e a edição de itens funcionam todos contra o ExtendDB sem alteração, então você ganha uma GUI de verdade sobre os seus dados auto-hospedados sem escrever scripts de scan.

Uma ressalva para planejar: o endpoint do ExtendDB é somente HTTPS, enquanto o perfil offline do DynoTable (como a maioria dos setups de DynamoDB-Local) mira em um host:port de loopback. Se o seu cliente ou ferramenta precisa de um listener de loopback em texto plano, termine o TLS na frente do ExtendDB (ou rode um proxy reverso local) e aponte a GUI para isso — o protocolo no fio ainda é DynamoDB JSON de qualquer jeito.

Armadilhas

• Não trate a v0.1 como DynamoDB de produção. Escalabilidade, latência e durabilidade são do seu PostgreSQL, não da AWS. Faça benchmark para a sua carga de trabalho antes de depender dele.
• Sem Global Tables / replicação entre regiões. Se o seu design depende de ativo-ativo multi-região, o ExtendDB não é o caminho — isso é um recurso do serviço gerenciado.
• Faça você mesmo o backup do banco de dados subjacente. Não há PITR gerenciado; um volume do PostgreSQL perdido se foi. Configure pg_dump / arquivamento de WAL como em qualquer outro PostgreSQL.
• As credenciais são as do próprio ExtendDB, não AWS IAM. Não espere que políticas, papéis ou chaves de condição do IAM governem o acesso — esse modelo de autorização não se transfere.

Próximos passos

• Modele primeiro os seus padrões de acesso — a mesma disciplina de single-table design se aplica, seja o backend o DynamoDB ou o PostgreSQL-via-ExtendDB.
• Construa e inspecione suas leituras e escritas com o Construtor de Expressões do DynamoDB, e então converta fixtures entre JSON puro e o formato de transporte com o conversor DynamoDB-JSON.
• Quando estiver pronto para mexer em uma instância ExtendDB ao vivo, conecte o DynoTable e navegue por ela como qualquer outra tabela.