A Microsoft tem um histórico longo com banco de dados. Do SQL Server nascido nos anos 80 ao Cosmos DB multi-modelo, a empresa sempre manteve suas apostas proprietárias. Mas quando o assunto é PostgreSQL gerenciado, o Azure Database for PostgreSQL Flexible Server sempre pareceu um wrapper fino sobre o Postgres vanilla. O HorizonDB muda essa história.

Anunciado em novembro de 2025 e disponível em preview limitado, o Azure HorizonDB é um serviço PostgreSQL-compatível com arquitetura cloud-native que separa compute de storage, usa uma engine de armazenamento escrita em Rust e inclui busca vetorial DiskANN embutida. O objetivo declarado: competir de frente com o Amazon Aurora e o Google AlloyDB.

O que é o Azure HorizonDB

HorizonDB não é um fork do PostgreSQL. É um serviço gerenciado que mantém compatibilidade wire-level com Postgres, mas substitui a camada de armazenamento por uma engine própria. Na prática, sua aplicação conecta usando qualquer driver PostgreSQL, executa queries SQL normais, mas por baixo os dados são persistidos e replicados por uma infraestrutura completamente diferente.

Segundo benchmarks internos da Microsoft, os números da preview impressionam:

  • Até 3.072 vCores distribuídos entre nós primários e réplicas
  • Storage compartilhado auto-escalável de até 128 TB
  • Latência de commit multi-zona abaixo de 1 milissegundo
  • Até 3x mais throughput que Postgres open-source em workloads transacionais

O serviço está em preview limitado em quatro regiões: Central US, West US3, UK South e Australia East. Não há data pública para GA nem informações de pricing.

Arquitetura: compute e storage desacoplados

A decisão arquitetural central do HorizonDB é a desagregação entre compute e storage. Em um PostgreSQL tradicional, os dados vivem no mesmo servidor que executa as queries. Se o servidor cai, o failover depende de replicar tudo para uma réplica standby e promovê-la. Quanto maior o banco, mais demorado o processo.

No HorizonDB, os nós de compute não armazenam dados. Eles processam queries e escrevem em um storage compartilhado distribuído entre zonas de disponibilidade. Adam Prout, partner architect na Microsoft, descreveu assim: "Estamos empurrando o máximo possível de trabalho de replicação e durabilidade para a camada de storage."

Isso tem consequências práticas. Se um nó de compute cai, outro sobe e conecta ao mesmo storage sem copiar dados, o que torna o recovery quase instantâneo. Você escala compute (mais vCores para queries pesadas) sem mover dados, e escala storage (mais TB) sem mexer nos nós de compute. Patches e upgrades acontecem com near-zero downtime porque o storage é independente do lifecycle dos nós.

Esse padrão não é novo. O Amazon Aurora usa arquitetura desagregada desde 2014 (inicialmente com MySQL, e desde 2017 com PostgreSQL), e o Google AlloyDB desde 2022. O que muda é a implementação, e a escolha de linguagem para o storage engine.

Por que Rust no storage engine?

A engine de armazenamento do HorizonDB é escrita majoritariamente em Rust. Algumas extensões PostgreSQL autorais da Microsoft e o índice vetorial DiskANN também usam Rust.

A escolha não é acidental. Em fevereiro de 2024, a Casa Branca publicou o relatório "Back to the Building Blocks" pedindo que desenvolvedores migrem para linguagens memory-safe. Em junho de 2025, CISA e NSA reforçaram a orientação com o guia "Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development". O recado: buffer overflows e race conditions respondem por uma fatia enorme de vulnerabilidades críticas, e linguagens como C e C++ perpetuam o problema.

Rust elimina essas classes de bug em tempo de compilação. Sem garbage collector, com ownership model que garante segurança de memória e concorrência. Para uma engine de storage que lida com dados críticos de clientes em ambiente multi-tenant, isso é um diferencial concreto.

A Microsoft não está sozinha nessa tendência. O TiKV (storage distribuído usado pelo TiDB) é escrito em Rust. O SurrealDB 3.0, lançado com US$ 44 milhões em funding total, tem engine Rust-nativa. O Materialize reescreveu componentes críticos em Rust. A mensagem do mercado é clara: para infraestrutura de dados que precisa ser rápida e segura, Rust cresce rapidamente como escolha estratégica.

DiskANN: busca vetorial dentro do Postgres

Além da engine de storage, o HorizonDB traz busca vetorial integrada via DiskANN, um algoritmo de índice desenvolvido pela Microsoft Research que funciona de forma diferente do HNSW usado pelo pgvector.

O HNSW (Hierarchical Navigable Small World) mantém o índice inteiro em memória. Funciona bem para datasets menores, mas o consumo de RAM escala linearmente com o número de vetores. Em datasets com dezenas de milhões de embeddings, a conta fica cara.

O DiskANN resolve isso mantendo a maior parte do índice em disco e carregando para memória apenas os trechos relevantes durante a busca. Benchmarks específicos divulgados pelo projeto do pgvectorscale (extensão da Timescale inspirada no DiskANN) mostram ganhos entre 39% e 363% em velocidade de busca comparado ao HNSW do pgvector em datasets de 1 milhão de embeddings OpenAI.

Mas o diferencial do DiskANN no HorizonDB vai além da performance bruta. O serviço implementa predicate pushdown no índice vetorial: filtros SQL são aplicados durante a travessia do grafo de vetores, não depois. No HNSW do pgvector, o parâmetro ef_search tem valor máximo de 1.000 candidatos, o que limita o recall em buscas com filtros restritivos (a versão 0.8.0 introduziu iterative_scan para contornar isso, mas é um ajuste manual). O DiskANN combina filtragem e busca em uma única operação, mantendo recall alto sem configuração extra.

Para aplicações de RAG e busca semântica que precisam combinar similaridade vetorial com filtros transacionais ("encontre documentos semelhantes a X onde o status é ativo e a data é posterior a Y"), essa integração é significativa.

O HorizonDB também inclui AI Model Management, integração direta com modelos do Microsoft Foundry para gerar embeddings e fazer reranking dentro do banco, sem configuração adicional.

HorizonDB vs Aurora vs AlloyDB

Os três grandes clouds convergem para o mesmo padrão: PostgreSQL-compatível, storage desacoplado e recursos de IA cada vez mais integrados à camada de dados.

Amazon Aurora PostgreSQL é o veterano. Disponível com suporte a PostgreSQL desde 2017, tem o maior track record operacional, opções serverless maduras e integração profunda com o ecossistema AWS (RDS Proxy, Bedrock, SageMaker). Sua maturidade é a principal vantagem. Equipes que já operam Aurora conhecem seus limites e suas quirks.

Google AlloyDB se diferencia pela capacidade analítica. Além de workloads transacionais, oferece queries analíticas near-real-time sobre os mesmos dados. O AlloyDB Omni permite rodar fora do GCP, em AWS, Azure ou on-premises, ampliando cenários híbridos e multi-cloud, algo que nem Aurora nem HorizonDB oferecem atualmente.

Azure HorizonDB aposta em três diferenciais: uma engine de armazenamento com componentes críticos escritos em Rust (segurança de memória em nível de infraestrutura), busca vetorial DiskANN nativa e integração com o ecossistema de IA da Microsoft para workflows de dados e AI.

O que falta no HorizonDB: ainda não há opção serverless comparável ao Aurora Serverless, a disponibilidade está restrita a poucas regiões em preview e não existe pricing público. Para workloads de produção hoje, Aurora e AlloyDB continuam escolhas mais maduras operacionalmente. Ainda assim, o HorizonDB sinaliza a direção: Rust no core, vetores nativos e IA embutida.

Conclusão

O HorizonDB não é apenas mais um PostgreSQL gerenciado. A decisão de reescrever o storage engine em Rust reflete uma mudança maior na indústria, o reconhecimento de que linguagens memory-safe não são luxo acadêmico, são requisito para infraestrutura crítica. A Casa Branca pediu. CISA e NSA documentaram. E agora a Microsoft implementou no serviço de banco de dados que pretende competir com Aurora e AlloyDB.

Para quem opera PostgreSQL em nuvem, o HorizonDB ainda não é uma opção para produção. Está em preview, com regiões limitadas e sem pricing. Mas vale acompanhar. A combinação de storage desacoplado, engine Rust e busca vetorial DiskANN nativa mostra que o próximo capítulo dos bancos de dados cloud-native não é apenas sobre escalar mais, é sobre escalar com segurança de memória garantida pelo compilador.

Quem quiser testar, o acesso ao preview está disponível em aka.ms/PreviewHorizonDB.

Referências pesquisadas nesta publicação