Shireesh Thota, CVP de Azure Databases na Microsoft, publicou em 13 de maio de 2026 um post detalhando o investimento da empresa no PostgreSQL. O texto mostra que a Microsoft contribuiu com 345 commits no release mais recente do banco e mantém committers oficiais no projeto upstream. Em paralelo, empilha capacidades de IA — vector search e invocação de modelo — dentro do Azure Database for PostgreSQL e do Azure HorizonDB.
O peso de 345 commits
PostgreSQL é um projeto open-source com mais de tres décadas de história e política de aceitação de patches conhecidamente exigente. Para fazer um commit entrar em um release, a contribuicao passa por uma comunidade revisora que olha qualidade de código, casos de teste e impacto em compatibilidade. 345 commits em um ciclo é volume relevante — e indica que a Microsoft não está apenas embalando PostgreSQL como serviço, mas também moldando para onde o motor cresce.
O que e um committer e por que importa
Um committer no PostgreSQL é alguém com direito de merge no repositório upstream. Eles aprovam patches escritos por outros desenvolvedores e influenciam decisões de arquitetura. Ter committers em folha de pagamento é sinal de comprometimento estratégico, não apenas comercial. A Microsoft junta-se a empresas como Crunchy Data, EnterpriseDB e Cybertec, que também investem em committers desde há anos.
A camada de IA no Azure Database
O movimento mais interessante para devs é a integração de IA dentro do banco. O Azure Database for PostgreSQL e o Azure HorizonDB — a oferta de Postgres distribuido da Microsoft — ganharam funções nativas para busca vetorial (vector search) e invocação de modelo diretamente em SQL. Em vez do código da aplicação ter que extrair embeddings, mandar para uma API de modelo e devolver para o banco, parte desse fluxo agora roda como função do próprio Postgres.
O que isso muda no dia a dia
Quem mantém aplicacao com RAG (retrieval-augmented generation, geração aumentada por recuperação) conhece a dor: a logica de embeddings, similarity search e chamada de LLM costuma viver em três camadas separadas. Com funções nativas, parte dessa logica pode descer para o banco. Em produção, isso significa menos round-trips de rede, menos código de orquestração e a possibilidade de fazer consultas que misturam SQL tradicional com busca por similaridade em uma única query.
A disputa entre hyperscalers
O PostgreSQL virou campo de batalha entre os três grandes provedores de nuvem. AWS investe em Aurora com vector e em RDS for PostgreSQL com extensões como pgvector. Google Cloud empurra AlloyDB com capacidades semelhantes. A Microsoft agora amplia a aposta com HorizonDB e features de IA embarcadas. A leitura de mercado é simples: PostgreSQL é hoje o ponto de entrada padrão para banco relacional sério, e o cliente que escolhe um provedor para rodar Postgres tende a ficar lá muito tempo.
Por que vector search dentro do banco
A promessa de manter vector search dentro do banco e nao em um serviço separado se sustenta em três argumentos. O primeiro é consistência transacional: dado relacional e embedding ficam no mesmo lugar, sem janela onde um existe e o outro ainda não. O segundo é simplicidade de stack: menos sistemas para monitorar e operar. O terceiro é governança: controle de acesso único, log único, backup único. A contraproposta de quem usa Pinecone, Weaviate ou Qdrant é que serviços dedicados têm features mais avancadas — hybrid search, reranking, multi-tenant melhor. A escolha continua sendo trade-off.
O que isso significa para times PostgreSQL
Para devs que já rodam PostgreSQL gerenciado no Azure, a leitura é que features de IA antes vistas como extensão opcional estão se tornando parte do produto principal. Vale acompanhar o ciclo de releases para entender quando essas funções ficam GA e em quais regiões. Para times que ainda hospedam o Postgres em VM ou Kubernetes próprios, a conta de migrar para o serviço gerenciado fica mais convidativa quando inclui esse pacote pronto.
Reportado originalmente por Microsoft Azure Blog em 2026-05-13.
