Postgres dentro do cluster de GPU, CNPG na CNCF e o Decider aberto da Perplexity: a pilha de dados da IA

O banco de dados saiu do porão: Postgres dentro do cluster de GPU e o modelo que decide virou open source

Três anúncios entre 11 e 12 de novembro de 2026 contam a mesma história por ângulos diferentes. A CoreWeave colocou um PostgreSQL gerenciado dentro dos clusters onde rodam as GPUs. O CloudNativePG, operador de Postgres para Kubernetes mais usado do mercado, virou projeto em incubação na CNCF e ganhou uma ferramenta de backup com quase zero perda de dados. E a Perplexity abriu, sob Apache 2.0, o modelo que os agentes dela usam para decidir — não para escrever. Juntas, as três notícias mostram onde a briga real da infraestrutura de IA está acontecendo: na camada de dados, não na de prompts.

CoreWeave leva o Postgres para o mesmo lugar da GPU

A partir de 11 de novembro, o CoreWeave Database está em disponibilidade geral: um serviço de PostgreSQL compatível que roda dentro do CoreWeave Kubernetes Service (CKS) do próprio cliente, ao lado das cargas de treino e inferência. O banco usa nós de CPU do cluster e já traz alta disponibilidade, backups contínuos e recuperação em um ponto no tempo (PITR).

O ganho óbvio é operacional: some o salto entre nuvens entre a aplicação de IA e o dado que ela consulta. Na prática, isso significa menos latência de rede, menos custo de egress, um único plano de identidade e uma pilha de observabilidade só. O risco também é óbvio: quanto mais a aplicação, o modelo e o banco moram no mesmo cluster, mais caro fica sair dele depois. Vale decidir com contrato, não só com benchmark.

CloudNativePG entra em incubação na CNCF — e o Klio muda o RPO

A EnterpriseDB (EDB) anunciou que o CloudNativePG (CNPG) foi aceito como projeto em incubação na CNCF. O operador foi criado pela própria EDB e é hoje o mais adotado para rodar Postgres sobre Kubernetes.

Junto vieram duas peças que importam para quem opera banco em cluster:

Klio , ferramenta de backup e recuperação para Postgres em Kubernetes, que segundo a EDB leva o projeto a uma perda de dados "próxima de zero";

o EDB Postgres AI Plugin for CloudNativePG , que injeta recursos de nível corporativo no operador.

O detalhe estratégico: o anúncio sai menos de uma semana depois de a EDB concluir a compra da Altinity, criadora do operador Kubernetes do ClickHouse. Ou seja, a mesma empresa passa a responder pelos dois operadores mais usados de banco em Kubernetes. Do lado bom, governança agora passa pela CNCF e não por um único fornecedor. Do lado de atenção, quem depende desses operadores deve acompanhar de perto a separação entre o que é aberto e o que virou produto pago.

O Decider v1.3: o modelo que decide, com pesos abertos

A Perplexity liberou em 12 de novembro o Decider v1.3 e o Decider Flash v1.3 , uma versão menor destilada do modelo maior. Os pesos estão no Hugging Face sob Apache 2.0 — com cerca de 26,1 bilhões e 4,5 bilhões de parâmetros, respectivamente — e também podem ser acessados via OpenRouter (de graça até 19 de novembro) e pela Decisions API.

O ponto conceitual é que o Decider não é um chatbot: em vez de gerar texto livre, ele devolve probabilidades calibradas para classificação e roteamento. É o tipo de modelo que fica escondido dentro de um agente para responder "esse pedido é elegível?", "essa consulta é sensível?", "qual ferramenta chamar agora?".

A versão 1.3 trouxe o locate , que extrai trechos exatos do texto — nomes, códigos de erro — com posição de caractere e uma nota de confiança. Os números divulgados pela empresa:

91,6% de acurácia média em 63 tarefas de classificação de consultas;

93,98% de concordância com um modelo de fronteira usado como juiz, em 1 milhão de requisições reais da Decisions API;

desempenho acima de modelos genéricos de extração em 17 tarefas fora de distribuição.

O caso de uso mais curioso é doméstico: a Perplexity relata que o Decider leu 1 bilhão de tokens em 7 mil sessões de agentes em um dia e apontou falhas que geraram 14 correções nas regras de segurança dos próprios agentes. O alerta técnico: requisições mistas — classificar e localizar no mesmo pedido — pagam latência extra, porque exigem passagens separadas pelo modelo.

O que muda para quem escreve código

Até agora, a discussão sobre agentes de IA girava em torno de qual modelo grande usar. As notícias desta semana deslocam o eixo para três camadas que precisam conversar: GPU, dados e decisão . Um Postgres no mesmo cluster da inferência, um operador de banco com governança de fundação e um classificador de pesos abertos para decidir o que o agente faz — esse é o esqueleto que começa a se repetir em produção.

A pergunta que fica é menos sobre adoção e mais sobre acoplamento: quanto do seu dado você aceita colocar fisicamente ao lado do seu modelo, e quanta da sua lógica de decisão você aceita entregar a um modelo que você não audita? As duas respostas vão definir o custo da sua arquitetura em 2027.

E aí, o seu time já trata a camada de dados como parte da stack de IA — ou ela ainda é o "porão" que ninguém quer visitar? Comenta aqui e compartilha com quem está desenhando a próxima migração.

Fontes