Write Ahead {B}Log

Quem trabalha com banco de dados na AWS já viveu essa história algumas vezes. O projeto começa simples, com um PostgreSQL provisionado, poucas conexões, carga previsível. Com o tempo, o sistema cresce, os usuários aumentam, surgem picos de tráfego, novas regiões, novas exigências de disponibilidade. De repente, o banco vira o ponto mais sensível da arquitetura.

Não porque o PostgreSQL seja ruim — muito pelo contrário — mas porque o modelo tradicional de banco relacional foi desenhado para um mundo muito mais estático do que o que a computação em nuvem nos impõe hoje.

Foi exatamente desse desconforto que nasceu o Amazon Aurora DSQL. A proposta é oferecer um banco relacional com SQL completo, baseado em PostgreSQL, que se comporte como um serviço distribuído, ativo-ativo, fortemente consistente e totalmente serverless.

O DSQL parte de uma pergunta simples, mas profunda:

E se o banco relacional pudesse escalar horizontalmente e eliminar o conceito de nó de escrita único, sem abrir mão da consistência?

O limite invisível do Postgres tradicional

Quando você usa um PostgreSQL tradicional (seja instalado no seu próprio servidor, rodando em uma EC2, no RDS ou mesmo no Aurora) cada vez que uma aplicação abre uma conexão com o banco, algo acontece por trás dos bastidores. O banco precisa validar quem está conectando, criar uma comunicação segura, separar memória e preparar uma sessão só para aquela conexão. Isso tudo tem custo.

E aqui está um ponto importante: mesmo quando a aplicação não está fazendo nada, aquela conexão continua ali, ocupando espaço e consumindo recursos. No começo, isso quase não aparece. A aplicação tem poucos usuários, poucas conexões abertas, tudo funciona bem. Mas, conforme o sistema cresce, o cenário muda. Mais usuários significam mais conexões ao mesmo tempo. Para dar conta disso, começam a surgir pools de conexão maiores. Em muitos casos, o banco precisa ser aumentado em sua capacidade não porque está lento no processamento de dados, mas simplesmente porque já não consegue aceitar mais conexões abertas.

Para aliviar essa pressão, entram soluções como PgBouncer ou RDS Proxy, que ajudam a reaproveitar conexões e evitar que cada requisição precise abrir uma nova sessão no banco. Isso resolve parte do problema, mas adiciona mais um componente para configurar, monitorar e manter.

Ao mesmo tempo, aparecem outros desafios clássicos. Normalmente existe um único banco responsável pelas escritas, o nó primário (writer). Se ele falha, é preciso promover uma réplica, atualizar endpoints e torcer para que a aplicação se reconecte sem grandes impactos. Para escalar leituras, entram as réplicas, que nem sempre estão totalmente sincronizadas. A aplicação precisa aprender quando pode ler de uma réplica e aceitar que, em alguns casos, os dados ainda não estão 100% atualizados.

Nada disso é erro de implementação. Esse modelo funciona e sustentou a maioria das aplicações por muitos anos. Mas ele vem acompanhado de decisões, ajustes e complexidades que vão se acumulando conforme o sistema cresce, e é exatamente esse conjunto de desafios que levou a AWS a repensar como um banco relacional poderia funcionar em um mundo realmente distribuído.

O que é, de fato, o Aurora DSQL

O Aurora DSQL é uma implementação distribuída de um banco relacional, construída sobre PostgreSQL, mas com uma arquitetura completamente diferente do Postgres tradicional.

Ele é totalmente serverless, não há instâncias para escolher, não há tamanho inicial, não há janela de manutenção, não há VPC obrigatória para começar. Você cria um cluster e, em poucos segundos, ele está pronto para receber conexões. Tudo o que normalmente é decisão antecipada passa a ser ajustável depois ou simplesmente abstraído.

Por baixo dos panos, o DSQL separa claramente três responsabilidades que, em bancos tradicionais, costumam estar fortemente acopladas.

O primeiro componente é o Query Processor, responsável por receber conexões no protocolo do PostgreSQL, interpretar SQL, planejar e executar consultas. É aqui que vivem as transações ativas, os dados temporários e a lógica relacional.

O segundo é o Journal, um log de transações distribuído, que garante durabilidade. É nele que acontece o verdadeiro “commit” da transação. Em ambientes single-region, esse commit já é gravado em múltiplas zonas de disponibilidade; em configurações multi-region, ele também é replicado entre regiões.

O terceiro é o Storage, que assina o journal, aprende sobre transações confirmadas e mantém uma visão local atualizada dos dados para responder leituras com baixa latência.

Essa separação permite algo fundamental: durante uma transação, os dados podem existir apenas na memória do Query Processor. Se a conexão cai ou ocorre um rollback, nada foi persistido. Só quando o commit é aceito pelo journal é que a transação se torna durável e visível para os demais componentes.

Consistência forte em um mundo distribuído

Um dos pontos mais interessantes é como o DSQL mantém consistência forte mesmo sendo distribuído.

Sempre que uma transação começa no DSQL, a primeira coisa que acontece é a definição de um momento no tempo (timestamp) muito preciso. A AWS usa serviços próprios de sincronização de relógio para garantir que esse horário seja extremamente confiável. Pense nisso como o banco dizendo: “a partir de agora, tudo o que você fizer nessa transação vai enxergar o mundo exatamente como ele está neste instante”.

Esse horário passa a ser a referência para todas as leituras feitas durante a transação. Enquanto isso, o armazenamento do DSQL usa uma técnica chamada MVCC (Multi-Version Concurrency Control), que basicamente permite manter várias versões dos mesmos dados ao mesmo tempo. Assim, quando uma consulta pede informações, o storage sabe exatamente qual versão devolver, sendo aquela que corresponde ao momento inicial da transação.

Na prática, isso gera um efeito muito poderoso. Várias conexões podem estar rodando ao mesmo tempo, em zonas de disponibilidade diferentes ou até em regiões diferentes, lendo e escrevendo dados em paralelo, sem perder a consistência. Cada uma enxerga o banco de forma estável e previsível, como se estivesse trabalhando sozinha.

Para quem desenvolve ou administra banco de dados, isso elimina uma preocupação comum: não é mais preciso decidir manualmente de qual réplica ler, nem aceitar leituras “um pouco atrasadas” como algo normal. O banco garante que todas as conexões vejam dados consistentes, independentemente de onde estejam rodando.

Esse detalhe muda completamente a experiência de quem desenvolve aplicações distribuídas sobre SQL.

Conexões sem dor de cabeça

Como o DSQL se baseia em PostgreSQL, ele precisa funcionar com tudo o que já existe nesse ecossistema, como drivers, ORMs, ferramentas de administração, bibliotecas e aplicações que falam o protocolo do PostgreSQL. Ao mesmo tempo, a AWS queria evitar um cenário comum em ambientes distribuídos: o cliente tendo que gerenciar múltiplos endpoints, lógica de balanceamento ou pools de conexão complexos.

Para quem está se conectando, cada cluster DSQL parece ter seu próprio endpoint, como qualquer banco tradicional. Por trás das cortinas, porém, a AWS usa um recurso do próprio TLS chamado SNI. Durante o início da conexão, o cliente informa para qual cluster está tentando se conectar, e o serviço usa essa informação para rotear a conexão dinamicamente para onde há capacidade disponível naquele momento. Isso permite escalar sem que o cliente precise se preocupar com nada disso.

Depois que a conexão é aceita, entra um ponto importante de segurança. Cada conexão no DSQL roda de forma isolada dentro de uma microVM baseada em Firecracker, a mesma tecnologia usada por serviços como AWS Lambda. Isso significa isolamento em nível de hardware, não apenas por processo ou container. Em termos práticos, mesmo que exista um ambiente multi-tenant por trás, uma conexão não tem como acessar dados ou memória de outra. Esse nível de isolamento não é um detalhe técnico, é uma escolha de arquitetura para reduzir riscos e aumentar a confiança no serviço.

Outro detalhe que faz muita diferença no dia a dia é como o DSQL lida com picos de conexões. Em bancos tradicionais, abrir uma nova conexão pode ser lento e caro. No DSQL, o serviço mantém pools “quentes” de capacidade já prontas para uso. Quando uma nova conexão chega, ela simplesmente é associada a uma dessas estruturas que já estão em memória, sem custo de inicialização perceptível.

O efeito prático disso é simples: você não precisa rodar PgBouncer, nem configurar RDS Proxy, nem pensar em como dimensionar pools de conexão. O pooling já faz parte do próprio serviço. Para quem desenvolve ou administra bancos, isso remove uma camada inteira de complexidade da arquitetura, sem abrir mão de performance, segurança ou compatibilidade com o mundo PostgreSQL.

Autenticação pensada para nuvem

Outro ponto importante é a autenticação. Em vez de senhas estáticas, o DSQL utiliza tokens temporários gerados via IAM, seguindo o mesmo princípio de requisições assinadas que já existe em serviços como S3 e DynamoDB.

Isso reduz drasticamente o risco de vazamento de credenciais e integra o banco ao modelo de governança da conta AWS com políticas, tags, controle por identidade e auditoria via CloudTrail.

Para quem já sofreu com rotação de senha ou credenciais esquecidas em variáveis de ambiente, esse detalhe faz diferença.

Escala automática e resiliência como padrão

O DSQL escala automaticamente tanto leitura quanto escrita. Novos Query Processors e réplicas de storage são criados conforme a carga aumenta, e o serviço se antecipa aos picos com base em observação contínua do uso.

Quando algo falha no DSQL, seja uma zona de disponibilidade, um host específico ou algum componente interno, isso não significa que o banco inteiro vai ficar indisponível. Na maioria dos casos, o impacto é parcial. Algumas conexões podem cair, mas outras continuam funcionando, e a própria aplicação consegue se reconectar de forma transparente, sem precisar de intervenções manuais ou decisões de emergência.

Um dos motivos para isso é que o DSQL não depende de um único nó responsável pelas escritas. Não existe o “writer principal” que, se cair, derruba tudo junto. Ao eliminar esse ponto único de sucesso, o DSQL remove uma classe inteira de problemas comuns em arquiteturas tradicionais, especialmente aqueles momentos críticos de failover em que é preciso promover uma réplica, atualizar endpoints e lidar com segundos de indisponibilidade.

Na prática, o banco passa a se comportar como um serviço distribuído, preparado para continuar funcionando mesmo enquanto partes dele estão se recuperando.

Como pensar em custo no DSQL

No Aurora DSQL, ao invés vez de pagar por instâncias, você paga por atividade.

O consumo é medido em DPUs (Distributed Processing Units), que representam o tempo efetivo de uso dos Query Processors, além de DPUs associadas a leituras e escritas com base nos bytes processados. O armazenamento é cobrado separadamente por GB-mês, independentemente do número de réplicas internas.

Na prática, isso significa que se sua aplicação “dorme”, o custo cai drasticamente. Se ela cresce, o custo cresce junto, de forma proporcional ao uso real. Não há necessidade de superdimensionar capacidade por garantia.

Quando o DSQL faz mais sentido

O Aurora DSQL não é um substituto automático para todo PostgreSQL existente. Ele brilha em cenários onde a elasticidade, a resiliência e a simplicidade operacional são mais importantes do que o controle fino sobre instâncias específicas.

Workloads transacionais modernos, aplicações distribuídas, APIs com picos imprevisíveis, sistemas que precisam crescer sem travar decisões técnicas são bons candidatos. Como qualquer serviço novo, o caminho mais saudável passa por provas de conceito reais, validação de drivers, testes de carga e análise de custo com dados concretos.

O DSQL não é um PostgresSQL melhorado, e também não é um substituto direto para RDS ou Aurora tradicional. Ele é uma resposta a um conjunto muito específico de dores que aparecem quando tentamos escalar bancos transacionais modernos mantendo consistência forte, alta disponibilidade e simplicidade operacional.

Você deve começar a considerar DSQL quando o gargalo deixa de ser apenas performance e passa a ser arquitetura e operação.

Em ambientes clássicos, escalar um banco relacional quase sempre significa lidar com um writer único. Mesmo com réplicas, proxies, read endpoints e failover automático, existe sempre um ponto central que concentra escrita, decisões e risco. Isso se traduz em manutenção planejada, janelas de indisponibilidade e testes de failover delicados.

No DSQL, qualquer Query Processor pode ler e escrever dados com consistência forte, em uma arquitetura ativa-ativa. Para nós DBAs, isso muda radicalmente o jogo, pois não há mais promoção de primário ou dependência de DNS para troca de papel. A disponibilidade passa a ser uma propriedade do sistema.

Outro ponto importante é quando o custo operacional começa a pesar mais do que o custo do serviço. Se você já precisou aumentar o tamanho de uma instância apenas para suportar mais conexões, você já sentiu essa dor. Pooling, PgBouncer, RDS Proxy e ajustes finos de limites resolvem até certo ponto. Depois disso, você está pagando por memória e CPU que não estão sendo usadas para processar dados, mas apenas para manter conexões abertas.

O DSQL resolve isso de forma estrutural. Conexões são tratadas como unidades efêmeras, isoladas em microVMs, escaladas automaticamente e cobradas apenas quando estão ativas.

DSQL também faz muito sentido quando resiliência deixa de ser um requisito teórico e vira uma exigência prática. O DSQL já nasce com replicação multi-AZ no journal e, opcionalmente, multi-region, garantindo durabilidade e consistência sem exigir arquiteturas paralelas ou sincronizações manuais.

Para quem vive banco de dados no dia a dia, talvez o aspecto mais interessante seja que o DSQL simplifica sem abrir mão de propriedades clássicas de bancos transacionais. Ele mantém ACID, MVCC, SQL completo, índices, transações e consistência forte. Isso o diferencia de abordagens NoSQL ou híbridas, que muitas vezes transferem complexidade para a aplicação.

Ao mesmo tempo, ele não tenta reproduzir tudo que um Postgres tradicional faz. Workloads fortemente analíticos, queries OLAP pesadas, relatórios longos ou operações que exigem controle fino de storage local continuam fazendo mais sentido em Aurora tradicional, Redshift ou engines especializadas. DSQL é claramente orientado a OLTP moderno, distribuído e elástico.

Um bom sinal de que você está no momento certo para avaliar DSQL é quando surgem perguntas como:

“Por que precisamos planejar janela de manutenção para um sistema crítico?”

“Por que o failover ainda exige ação manual?”

“Por que precisamos explicar eventual consistency para o time de produto?”

“Por que escalar conexões custa tão caro?”

“Por que alta disponibilidade ainda é um projeto, e não um padrão?”

Em resumo: considere o Amazon Aurora DSQL quando seu maior desafio não for mais como operar o banco, mas como não deixar que o banco limite a evolução do sistema. Se você chegou nesse ponto, vale muito a pena olhar com calma.

É importante destacar que, apesar de todas as vantagens, o Aurora DSQL ainda tem algumas limitações importantes que merecem ser consideradas antes de adotá-lo como solução única.

Primeiro, ele não expõe todas as tabelas de sistema e métricas internas que você encontra em um PostgreSQL tradicional, e isso significa que algumas consultas administrativas ou ferramentas que dependem desse tipo de visão podem não funcionar da mesma forma.

Também existem quotas e limites configuráveis, como o número máximo de conexões por cluster ou limites em objetos e recursos que, em alguns cenários de uso muito intensivo, podem exigir planejamento adicional.

Além disso, embora o DSQL seja compatível com a maior parte dos tipos de dados do PostgreSQL, nem todos os tipos e extensões são totalmente suportados e isso pode impactar aplicações que dependem de tipos de dados ou extensões específicas que ainda não foram implementados no serviço.

Em outras palavras, DSQL oferece um modelo distribuído e escalável, mas não é um clone exato de um PostgreSQL completo, e entender essas diferenças ajuda a evitar surpresas durante migrações ou integrações.

Avaliando a migração para Amazon Aurora DSQL

Antes de pensar em migração, é necessário entender por qual razão você está considerando DSQL. Abaixo segue um guia de perguntas para compreender se o seu cenário é adequado para adoção da tecnologia:

1. Tipo de workload

• O banco é predominantemente OLTP?
• As transações são curtas e frequentes?
• O acesso é concorrente, com muitos clientes ou serviços ao mesmo tempo?
• O workload exige consistência forte?

2. Escalabilidade

• Você já escalou instâncias mais pelo número de conexões do que por CPU?
• Sofre com o problema de picos de acesso imprevisíveis? Usa PgBouncer, RDS Proxy ou soluções similares?

3. Disponibilidade e resiliência

• Failover ainda é um evento que exige atenção humana?
• Testes de DR são raros, delicados ou geram insegurança?
• O RTO/RPO exigido é incompatível com modelos tradicionais?

4. Modelo de dados

• O schema é relacional e bem definido?
• Não depende fortemente de extensões específicas do Postgres?
• Usa SQL padrão, índices e transações tradicionais?

5. Modelo de custos

• O custo atual está mais ligado a “instância ligada” do que a uso real?
• O workload tem variação clara ao longo do dia ou da semana?
• Existe interesse em pagar por atividade, não por capacidade provisionada?

Se a maior parte das respostas for “sim”, o DSQL pode ser uma boa opção.

Quando NÃO usar Amazon Aurora DSQL

Tão importante quanto saber quando usar, é saber quando não usar. DSQL não é bala de prata, e ignorar isso pode gerar problemas no futuro.

1. Não use DSQL se o workload for analítico

DSQL não foi feito para OLAP pesado, relatórios longos ou scans massivos.
Se o uso principal envolve agregações grandes, joins complexos e leitura de grandes volumes históricos, engines analíticas continuam sendo a escolha certa.

2. Não use DSQL se você depende fortemente de extensões específicas

Embora seja baseado em Postgres, DSQL não suporta todas as extensões.
Workloads que dependem de extensões ou comportamentos específicos do engine tradicional podem não ser bons candidatos.

3. Não use DSQL se o sistema é pequeno, estável e previsível

Se você tem poucas conexões, carga previsível, crescimento lento, baixo risco de indisponibilidade, um RDS ou Aurora tradicional provavelmente serão mais simples e econômicos.

4. Não use DSQL se a aplicação não tolera reconexões

DSQL é resiliente, mas falhas acontecem. Se a aplicação não lida bem com retries, timeouts, ou reabertura de conexões, não há benefícios na migração.

5. Não use DSQL se você precisa de controle total da infraestrutura

Se você precisa definir tamanho de instância, controlar patches, configurar sistema operacional ou mexer em parâmetros de baixo nível, o DSQL não é o modelo certo.

6. Não use DSQL apenas porque é novo

O DSQL resolve problemas reais, mas se esses problemas não existem no seu contexto, ele só adiciona uma camada desnecessária de abstração. Tecnologia boa no lugar errado vira débito técnico.

Conclusão

Para quem trabalha com banco de dados, o Amazon Aurora DSQL representa uma mudança importante na forma como pensamos bancos relacionais na nuvem. Ele não surge para invalidar o PostgreSQL tradicional, mas para reconhecer que o contexto mudou. As aplicações deixaram de ser estáticas, os padrões de acesso ficaram imprevisíveis e a expectativa de disponibilidade hoje é muito mais alta do que como o modelo clássico foi desenhado para sustentar sozinho.

O Aurora DSQL nasce incorporando conceitos profundamente conhecidos em bancos de dados relacionais, como SQL, transações, ACID, MVCC, e os combina com uma arquitetura distribuída inspirada em serviços que a AWS opera há anos em escala global. O impacto prático disso é profundo: o banco passa a oferecer disponibilidade, escala e isolamento como características nativas, não como cenários excepcionais que precisam ser cuidadosamente orquestrados.

Talvez o maior valor do DSQL não esteja apenas na arquitetura, mas na mudança de mentalidade que ele permite. Em vez de projetar sistemas já pensando em contornar limitações do banco, os times passam a projetar pensando primeiro no negócio, na experiência e na evolução natural da aplicação.

Isso não torna o DSQL uma escolha universal. Ele tem limites claros, faz concessões conscientes e não tenta cobrir todos os cenários possíveis. Workloads estáveis, previsíveis ou fortemente dependentes de extensões específicas continuam muito bem atendidos por modelos tradicionais.

No fim, arquitetar bancos de dados sempre foi sobre equilíbrio. O Aurora DSQL não elimina a necessidade de boas decisões, ele apenas devolve algo que muitos times perderam ao longo do caminho: margem para evoluir sistemas sem viver constantemente à beira do próximo incidente.

Referências

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/what-is-aurora-dsql.html

AWS re:Invent 2025 — Deep dive into Amazon Aurora DSQL and its architecture (DAT439)