Aurora DSQL ganha chaves estrangeiras depois de quase dois anos sem suporte

A AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → anunciou que o Aurora DSQL, seu banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → serverless e distribuído compatível com PostgreSQL, passou a suportar constraints de chave estrangeira, incluindo ações referenciais como CASCADE e SET NULL. A notícia foi reportada pelo InfoQ em 28 de setembro de 2026 e fecha uma lacuna que a própria comunidade técnica vinha cobrando desde o lançamento do serviço, no re:Invent 2024.

A ausência de foreign keys era, até aqui, o motivo mais citado para não migrar sistemas legados de Postgres para o DSQL. Sem esse recurso, aplicações que dependiam de integridade referencial no nível do banco precisavam reimplementar essa lógica na camada de aplicação, o que na prática inviabilizava boa parte das migrações de bases já existentes (brownfield).

Como a verificação funciona sem travar tabelas

O ponto técnico mais relevante para quem projeta schemas distribuídos é a forma como o Aurora DSQL implementa a integridade referencial. Segundo a documentação da AWS citada pelo InfoQ, o serviço não usa locks tradicionais de tabela. Em vez disso, ele faz snapshot verification durante a transação e detecção de conflito no momento do commit.

Na prática, isso significa:

• As relações de chave estrangeira são checadas contra um snapshot consistente da transação, sem bloquear leituras ou escritas concorrentes.
• No commit, o banco usa checagens implícitas de KEY SHARE (mecanismo do próprio Postgres) para detectar mudanças conflitantes nas linhas referenciadas.
• Transações que violariam uma constraint são rejeitadas com um erro de serialização, não ficam esperando em fila.

Marc Brooker, VP e Distinguished Engineer da AWS, descreveu o mecanismo por trás disso, batizado de Adjudicator, resumindo o comportamento esperado: sem bloqueio, sem mudança na escala para leituras que não envolvem foreign keys, leitores que checam FKC nunca fazem outros leitores abortarem, e boa escalabilidade para cargas bem distribuídas (fonte).

O que muda no design de aplicações

Para quem constrói sobre o DSQL, a consequência direta é arquitetural: como conflitos geram falha de transação em vez de espera, a aplicação precisa implementar lógica de retry. Isso é diferente do modelo mental que a maioria dos desenvolvedores carrega do Postgres tradicional, onde locks pessimistas seguram a transação concorrente até a liberação do recurso.

A AWS também recomenda um cuidado específico de modelagem: para linhas muito referenciadas (uma tabela de usuários referenciada por dezenas de outras, por exemplo), é melhor evitar colunas de chave que mudam com frequência. A orientação é manter as chaves referenciadas estáveis e mover valores que mudam bastante para colunas que não fazem parte da chave, reduzindo assim os conflitos de transação.

Esse é um trade-off real de custo: a AWS afirma que toda operação DML em tabelas referenciadas ou que referenciam outras passa a fazer leituras adicionais para manter a integridade referencial, e recomenda explicitamente que equipes façam benchmark da carga de trabalho antes de adicionar uma constraint de chave estrangeira a uma tabela em produção.

A pressão da comunidade que motivou a mudança

O histórico da demanda é bem documentado. Quando o Aurora DSQL foi anunciado no re:Invent 2024, a falta de foreign keys já era apontada como uma das principais limitações. Um usuário identificado como SteveTabernacle2 chegou a questionar o próprio posicionamento do produto na época: "Postgres-compatible" é enganoso. Foreign keys são uma parte tão grande de RDBMS. Você não pode ter dados verdadeiramente "relacionais" sem chaves estrangeiras.

A resposta da AWS veio de Marc Bowes, senior principal engineer da empresa, em uma thread conhecida como "Amazon wasted their time building DSQL": "E sim, as foreign keys estão vindo. Nós ouvimos vocês."

Agora que o recurso chegou, a reação de quem lida com migração de sistemas legados foi rápida. Luc van Donkersgoed, principal engineer na Nederlandse Spoorwegen (a operadora ferroviária nacional holandesa) e criador do AWS News Feed, comentou no LinkedIn: "Eles fizeram! O Aurora DSQL agora suporta foreign key constraints. A falta de FKs era a maior lacuna entre o DSQL e o Postgres 'normal', bloqueando muitas migrações. Essa mudança torna o DSQL muito mais viável para ambientes brownfield."

O ceticismo que ainda resta

Nem toda reação foi só comemoração. Em uma thread no Reddit citada pelo InfoQ, um usuário levantou a dúvida que mais importa para quem vai colocar isso em produção: "Eu sei que esse recurso foi apontado como um dos principais bloqueadores de adoção, mas isso deixa as coisas bem mais lentas. Não tenho certeza de quão bom isso vai ser considerando a arquitetura do DSQL."

A preocupação faz sentido dado o próprio aviso da AWS sobre leituras adicionais em cada operação DML. Diferente de um Postgres rodando numa única instância, o DSQL é distribuído por design, e qualquer mecanismo de verificação de integridade referencial tem custo de coordenação entre nós. A recomendação de benchmarking antes de aplicar a constraint não é só cautela genérica, é reconhecimento explícito de que o impacto de performance varia por workload.

Contexto adicional: CloudWatch Database Insights

A chegada das foreign keys não foi a única novidade recente no DSQL. A AWS também adicionou suporte ao CloudWatch Database Insights, com monitoramento por statement e no nível de cluster, permitindo troubleshooting de performance mais granular. Para equipes que vão testar constraints de chave estrangeira em cargas reais, essa ferramenta é o caminho natural para medir o impacto das leituras adicionais mencionadas pela própria AWS antes de decidir se vale a pena aplicar a constraint em tabelas de alto tráfego.

O que fica em aberto para quem avalia o DSQL

Para equipes brasileiras que hoje mantêm bases Postgres tradicionais e cogitam migrar para um banco serverless com escala automática, o recurso remove uma barreira de entrada real, mas não elimina a necessidade de repensar padrões de acesso a dados. Quem migra precisa validar dois pontos concretos antes de decidir: se a aplicação já trata erros de serialização com retry (ou precisa ser adaptada para isso), e se o schema tem colunas de chave que mudam com frequência e que precisariam ser remodeladas para reduzir conflitos. Nenhum desses dois pontos é trivial de resolver depois que o sistema já está em produção.

Fonte: InfoQ