--- title: "Arquiteturas de banco de dados desagregadas estão mudando a nuvem. Entenda o conceito" author: "Gabriela P. Torres" date: "2026-08-01 09:30:00-03" category: "Tecnologia & Desenvolvimento" url: "http://desbugados.scale.press/portal/desbugados/post/2026/08/01/arquiteturas-de-banco-de-dados-desagregadas-estao-mudando-a-nuvem-entenda-o-conceito/md" --- ## Resumo - A desagregação é o ato de separar a camada de computação da camada de armazenamento em um banco de dados, permitindo que cada uma seja escalada de forma independente. - O principal motivador econômico é a assimetria: computação é muito mais cara e flutua rapidamente, enquanto armazenamento é barato e cresce lentamente. - Exemplos reais como Amazon Aurora (2015), Alibaba PolarDB (2018) e Amazon DSQL (2025) mostram a adoção massiva desse modelo pelos hiperescaladores. - Apesar dos benefícios, estudos indicam um custo de performance: bancos desagregados podem ter até 10x menos throughput em comparação com arquiteturas 'shared-nothing' otimizadas. - Novos protocolos e técnicas, como o uso de logs compartilhados e pushdown de computação, surgem para mitigar os trade-offs de performance. - A tendência vai além do armazenamento, com arquiteturas como o PolarDB-CXL explorando a desagregação da própria memória RAM. - Para o profissional de TI, a mensagem é clara: arquiteturas desagregadas oferecem elasticidade e custo sob demanda, mas exigem atenção aos gargalos de rede e latência. --- Imagine que você está gerenciando um restaurante tradicional. O cozinheiro (a camada de computação) precisa sempre estar ao lado da geladeira (a camada de armazenamento) para pegar os ingredientes. Se o restaurante fica lotado, você precisa contratar mais cozinheiros e comprar mais geladeiras, mesmo que o problema seja só a falta de mãos na cozinha. Agora, imagine um modelo diferente: um armazém centralizado com entregadores rápidos levando os ingredientes para qualquer cozinheiro livre em qualquer cozinha da cidade. É exatamente essa a ideia por trás da revolução silenciosa que está redesenhando a arquitetura dos bancos de dados na nuvem, e que **Murat Demirbas**, Cientista de Pesquisa Principal no MongoDB e ex-cientista na AWS, vai detalhar em sua palestra "Parting the Clouds: The Rise of Disaggregated Systems" na **QCon San Francisco 2025**. ## Do tudo-em-um para a separação de poderes Por décadas, desde os anos 1970 com sistemas como **Postgres** e **MySQL**, a arquitetura dominante foi a "monolítica", onde computação, memória e armazenamento residem no mesmo servidor. Mesmo com a evolução para sistemas replicados usando protocolos como Paxos ou Raft — onde um nó primário aceita escritas e seguidores replicam os dados —, o gargalo fundamental persistia: cada servidor físico precisava carregar todo o fardo. A desagregação, como explicam os pesquisadores no artigo acadêmico publicado na **VLDB 2025** e resumido por Demirbas em seu blog em setembro de 2025, nasce de uma constatação econômica brutal. Existe uma assimetria fundamental na nuvem: a camada de computação é significativamente mais cara do que a de armazenamento. Além disso, a demanda por computação flutua drasticamente (um site de e-commerce em Black Friday versus uma terça-feira comum), enquanto a demanda por armazenamento muda lentamente e de forma previsível. Por fim, a camada de computação é frequentemente "stateless" (sem estado, não guarda dados permanentemente), enquanto a de armazenamento é "stateful" (mantém o estado). Separar os dois permite tratar cada um de acordo com sua natureza. ## A anatomia de um banco desagregado: Aurora, PolarDB e Socrates Se a teoria é a separação, como ela funciona na prática? Vamos olhar para os pioneiros. A **Amazon Aurora**, lançada em 2015, é considerada o primeiro grande sistema OLTP (processamento de transações online) desagregado. Seu truque arquitetônico foi usar o log de redo — o registro de todas as alterações feitas no banco — como o protocolo de comunicação entre o nó de computação e o sistema de armazenamento distribuído. Em vez de mover blocos de dados inteiros, a Aurora envia apenas o "diário de mudanças" para quóruns de nós de armazenamento (exigindo confirmação de 4 de 6 nós), reduzindo drasticamente o tráfego de rede. Outro exemplo de peso é o **Alibaba PolarDB**, de 2018, que levou o conceito mais adiante com o uso de **RDMA** (Acesso à Memória Remota Direta, uma tecnologia de rede de altíssima velocidade que permite que um computador acesse a memória de outro sem envolver o sistema operacional) e protocolos de **Raft Paralelo**, usando um quórum de 2 de 3 nós. A **Microsoft**, com seu **Azure Socrates** em 2019, introduziu uma desagregação ainda mais granular dentro da própria camada de armazenamento, dividindo-a em um Serviço de Log (com pegada pequena e latência estrita), um Cache de Páginas e um Armazenamento Durável de Páginas. Se você achou que o assunto parou por aí, a **Huawei** entrou em 2020 com o **TaurusDB** e o **Google** em 2022 com o **AlloyDB**. ## O custo escondido: quando a rede vira o gargalo Aqui é preciso parar de ler os comunicados de imprensa e olhar para os dados. A desagregação não é uma pílula mágica sem efeitos colaterais. O artigo da VLDB'25 cita um estudo de 2019 que revela um dado crucial para qualquer arquiteto de sistemas: bancos de dados desagregados podem sofrer um impacto de **até 10 vezes no throughput** (a capacidade de processar transações por segundo) em comparação com um sistema "shared-nothing" (nada compartilhado) altamente otimizado. O motivo? A rede. Quando você separa o cérebro (computação) do músculo (armazenamento), cada operação de leitura ou escrita que antes era uma chamada local de memória ou disco agora precisa percorrer a rede. A latência acumulada dessas viagens de ida e volta, sob carga pesada, se torna o novo vilão. É por isso que as implementações mais modernas, como o Aurora DSQL da Amazon — que atingiu disponibilidade geral em 2025 e no qual Demirbas trabalhou por dois anos —, precisam de engenharia extrema para otimizar o caminho de rede e usar técnicas de cache agressivo para mascarar essa latência. ## A nova fronteira: desagregando até a memória RAM Se a indústria já separou computação de armazenamento em disco, a próxima fronteira lógica é desagregar a própria memória RAM. E isso já está acontecendo. O **PolarDB** da Alibaba, por exemplo, já explora um caminho além do armazenamento tradicional, propondo uma arquitetura com um pool compartilhado de memória remota. Essa memória pode ser provisionada, escalada e compartilhada de forma independente, usando redes de alta velocidade como RDMA ou a emergente tecnologia **CXL** (Compute Express Link) para mitigar a latência. O site Transactional.blog, em suas notas sobre sistemas OLTP desagregados, descreve a arquitetura **PolarDB-CXL**, onde um switch CXL é alimentado de forma independente e os dados na memória CXL permanecem intactos mesmo em caso de falha da máquina de computação. Isso resolve um dos maiores pesadelos de sistemas in-memory: a perda de estruturas de dados voláteis durante uma pane. Para atacar os problemas de performance inerentes a tanta separação, a pesquisa acadêmica não para. Protocolos como o **Cornus 2PC** (de 2022) propõem usar logs compartilhados para coordenar transações distribuídas de forma mais eficiente. Outras abordagens focam em "pushdown", ou seja, empurrar a computação para mais perto dos dados. O **PushdownDB**, por exemplo, mostrou ser capaz de cortar o tempo de consultas em **6,7 vezes** e reduzir custos em **30%** ao executar parte do processamento diretamente na camada de armazenamento, evitando que dados cruem a rede desnecessariamente. ## Além do hype: o que isso significa para o seu trabalho Entender essa mudança arquitetônica vai muito além de acompanhar o lançamento de mais um serviço gerenciado. Ela redefine os trade-offs que todo profissional de TI precisa considerar ao projetar sistemas. A promessa da desagregação é uma elasticidade quase perfeita: a capacidade de computação pode subir e descer até zero, permitindo um modelo de pagamento verdadeiramente "pay-per-use" (pague pelo que usar). A recuperação de falhas também se torna mais rápida e isolada, já que um nó de computação com problema pode ser descartado e substituído sem afetar os dados duráveis no armazenamento compartilhado. No entanto, como a palestra de Demirbas na QCon vai explorar, essa mudança traz novos desafios de design. Escolhas como "log-as-database" (usar o log como a verdade absoluta), a replicação via armazenamento compartilhado e a criação de camadas de cache sofisticadas afetam diretamente o throughput, a latência e, claro, a fatura final. O custo de performance de até 10x, conforme documentado, não é desprezível e exige uma análise cuidadosa do perfil de carga de trabalho da sua aplicação. Para o profissional curioso, a lição é que a arquitetura de nuvem moderna é sobre componentização e especialização, onde cada parte do sistema faz uma coisa e a faz muito bem — mas a comunicação entre essas partes se torna o novo ponto de atenção.