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.