Algumas Notas do Databricks Data + AI Summit 2026: Por Que a Camada de Dados Importa Novamente
Depois do Databricks Data + AI Summit deste ano, percebi que estava pensando menos sobre qualquer anúncio específico e mais sobre uma pergunta que está comigo há algum tempo:
Quando a IA realmente entra em produção, em que a camada de dados se torna?
Minha resposta atual é simples, embora as implicações não sejam: neste ciclo, a camada de dados é a parte da stack de IA que foi reprecificada mais lentamente. Isso está começando a mudar.
Dados: a parte da stack de IA que o mercado ainda não precificou
Algoritmos foram reprecificados em público. Modelos melhoram rapidamente, e a indústria consegue ver o progresso quase toda semana. Computação foi reprecificada pela NVIDIA, pelos provedores de nuvem e pelos mercados de capitais. Todo mundo entende que GPUs importam.
Dados se moveram mais lentamente. Não porque importem menos. O oposto é verdadeiro. Dados são lentos para reprecificar porque são difíceis de discutir e ainda mais difíceis de corrigir. Dados corporativos são bagunçados, espalhados, duplicados, desatualizados e cheios de permissões que ninguém entende completamente. Semânticas de negócio não se alinham de forma limpa entre sistemas. Aquilo que as pessoas chamam de “tempo real” muitas vezes ainda é uma tarefa agendada que rodou em algum momento da noite passada.
Esse trabalho é doloroso. Também não é muito glamouroso. Mas, quando a IA sai das demonstrações e entra em produção, a dor se torna impossível de esconder.
Em conversas com pessoas que constroem e treinam modelos, incluindo aquelas na OpenAI e na Anthropic, a discussão frequentemente volta ao mesmo ponto. Modelos estão convergindo. Computação pode ser comprada, pelo menos se você tiver dinheiro suficiente. A camada defensável está se tornando cada vez mais os dados: sua qualidade, sua atualidade, as permissões ao seu redor e a velocidade com que podem ser transformados em contexto útil.
Isso não é apenas um problema da camada de aplicação. Dentro de empresas de modelos, a qualidade do modelo ainda depende fortemente do pipeline de dados. Uma execução de treinamento pode exigir dias de preparação antes que o primeiro experimento sério comece. Se um campo upstream estiver sujo, um lote estiver rotulado incorretamente ou uma regra de filtragem estiver errada, dias de computação e espera podem desaparecer antes que alguém perceba que a curva de perda se desviou.
Agentes de IA tornam o problema dos dados impossível de esconder
Agentes expõem o mesmo problema de uma forma mais operacional.
Quando agentes de IA falham em produção, a primeira causa frequentemente não é que o modelo seja incapaz. É que o modelo está agindo com o contexto errado: um registro que ele não consegue acessar, um documento que expirou seis horas atrás, uma fonte de dados que mudou silenciosamente durante a noite ou um caminho de recuperação que é caro demais para ser usado com frequência suficiente. Recentemente, vi uma equipe forte perder quase uma semana por causa de um pipeline de contexto desatualizado. O agente estava respondendo com confiança à pergunta de ontem. O modelo não era burro. O contexto estava errado, e o sistema não tinha uma forma limpa de provar onde o erro entrou no ciclo.
Esse é o modo de falha que importa. O próximo gargalo de infraestrutura não é simplesmente um raciocínio melhor. É contexto atualizado, confiável, barato e auditável no momento em que um modelo ou agente toma uma decisão.
É por isso que acho que a camada de dados é a próxima parte da stack de IA a ser reprecificada.
A Databricks está mirando no problema certo
Sou cético em relação a muitos produtos que se autodenominam “plataformas de dados de IA.” Com frequência demais, a história chega antes do sistema.
A Databricks é diferente o suficiente para que eu ache que merece atenção séria. Duas coisas se destacaram para mim no Summit.
A primeira ainda é a cultura de engenharia. Na escala da Databricks, seria fácil para a empresa se tornar puramente orientada a vendas. Ainda assim, os fundadores continuam no palco falando sobre mecanismos de execução, transações, análises em tempo real e os encanamentos por baixo do produto. Respeito isso. Você consegue sentir quando uma empresa ainda tem intuição de produto e engenharia em seu núcleo. Isso aparece em pequenas decisões arquiteturais muito antes de aparecer em uma keynote.
O segundo é a base de clientes. Os usuários com quem conversei no Summit não estavam falando sobre IA como uma camada de demonstração. Eles estavam tentando levar a IA para sistemas de produção, e os problemas que descreveram eram muito mais concretos: agentes precisam ler e escrever estado de negócio; análises em tempo real não podem continuar pagando o custo de mover dados; pipelines precisam se tornar mais autônomos; o comportamento dos agentes precisa de governança em runtime, não apenas depois do fato.
É por isso que anúncios como Lakebase, Lakehouse//RT, agentes de dados e governança de IA importam. Os nomes são menos importantes do que a direção. Coloque transações mais perto do lake. Traga as análises em tempo real de volta para a mesma fundação de dados. Automatize mais do pipeline. Estenda a governança de “quem pode ver este dataset” para “o que este agente tem permissão para fazer nesta etapa específica?”
Não vejo isso como uma direção errada. Vejo como evidência de que muitos de nós estamos olhando para o mesmo futuro a partir de ângulos diferentes.
O banco de dados está se expandindo. Ele não é mais apenas um lugar para armazenar e consultar dados. Está se tornando a fundação para fatos, estado, semântica, governança e ação.
O mapa é bom. Mas não está terminado.
A Databricks está certa na direção. Isso não significa que a arquitetura tenha alcançado sua forma final.
Foto: The Known Data Realm · Databricks Data + AI Summit 2026
Vejo três áreas em que o mapa ainda está incompleto.
O lakebase em si.
Começar com Postgres é um ponto de entrada inteligente. Desenvolvedores o conhecem. O ecossistema é enorme. A compatibilidade reduz a fricção de adoção. Isso importa.
Mas a arquitetura que coloca as pessoas pela porta nem sempre é a arquitetura que vence a carga de trabalho final.
Sistemas operacionais da era da IA precisam de transações, memória, vetores, dados multimodais, rastreamento, ramificação, rollback e isolamento de tenants muito granular. Um núcleo relacional tradicional pode expor alguns desses recursos por meio de extensões e serviços ao redor, mas isso não os torna nativos. O Postgres clássico não foi projetado para escala distribuída cloud-native, nem para agentes que criam bancos de dados de curta duração, bifurcam estado, escrevem na memória, geram traces e desaparecem.
Mover o Postgres para mais perto do armazenamento de objetos não elimina essas questões. O armazenamento de objetos é barato e confiável, mas não é de baixa latência por padrão. Para fazê-lo parecer rápido, você precisa de uma camada de cache que seja ao mesmo tempo agressiva e correta. Um cache que permaneça estável sob carga transacional real é um dos problemas de sistemas mais difíceis em bancos de dados. Então minha pergunta honesta sobre o Lakebase não é se a demonstração é impressionante. É se o sistema consegue sustentar cargas de trabalho OLTP reais em escala de produção sem transformar esse cache na coisa que acorda as pessoas às 3 da manhã.
Os dados multimodais.
A Databricks desenhou um mapa forte entre OLTP, warehousing, análises em tempo real, ciência de dados e governança. Mas aplicações de IA consomem cada vez mais texto, imagens, áudio, vídeo, embeddings, logs de comportamento e traces de agentes. Esses não são apenas objetos ao lado de tabelas. São os dados que os agentes recuperam, sobre os quais raciocinam, transformam e escrevem de volta.
Se os dados multimodais permanecerem fora do mapa central, então os ativos de dados de IA mais importantes ainda viverão nas margens.
O usuário padrão.
Grande parte da superfície do produto ainda pressupõe um usuário humano: dashboards, BI em linguagem natural, fluxos de trabalho no estilo Excel e experiências voltadas para analistas. Isso é valioso. Mas agentes usam bancos de dados de maneira diferente.
Um agente não abre um dashboard uma vez por dia. Ele roda em um loop. Recupera contexto, toma uma decisão, chama uma ferramenta, escreve estado, verifica uma política e repete. Cada etapa pode precisar ser auditada. Cada recuperação pode influenciar a próxima ação. Cada escrita pode precisar de rollback. Cada verificação de permissão pode precisar acontecer em runtime.
Isso é uma carga de trabalho de banco de dados diferente.
Foto: Unity AI Gateway · Governança —— Databricks Data + AI Summit 2026
Quando o usuário do banco de dados é um agente
Durante décadas, um banco de dados podia se concentrar principalmente em uma pergunta: como executar esta consulta corretamente e rapidamente.
Na era dos agentes, a pergunta se torna mais ampla:
Como um agente obtém o contexto mais atualizado, mais confiável, de menor custo e mais auditável no momento em que toma uma decisão?
Isso não é apenas um problema de otimização de consultas. É um problema de sistemas que envolve armazenamento, indexação, governança, linhagem, replay, controle de custos e aplicação de políticas em tempo de execução.
É aqui que a categoria começa a mudar. Um sistema de dados não pode mais ser apenas um sistema de inteligência: você faz uma pergunta, ele retorna uma resposta. Ele precisa se tornar mais próximo de um sistema operacional para IA: o lugar onde agentes leem contexto, tomam decisões, chamam ferramentas, escrevem estado e deixam para trás um rastro que humanos e outros sistemas possam inspecionar.
A auditabilidade não pode ser adicionada depois do fato. Se um agente der a resposta errada, tomar a ação errada ou gastar dinheiro demais, a primeira pergunta será: o que exatamente ele viu naquele momento?
Para responder a isso, o sistema precisa saber quais documentos foram recuperados, quais vetores foram correspondidos, quais filtros de metadados foram aplicados, qual reranker mudou a ordem, qual ferramenta foi chamada, que política foi aplicada e que estado foi gravado de volta. Depuração e governança se tornam o mesmo fluxo de trabalho.
Essa é a arquitetura que eu não acho que alguém já tenha resolvido completamente.
O que “nativo de IA” deveria realmente significar
“Nativo de IA” está se tornando uma daquelas expressões que podem significar quase qualquer coisa. Eu não acho que ainda exista uma definição clara. Mas, se trabalharmos de trás para frente a partir de cargas de trabalho reais de agentes, um sistema de dados nativo de IA precisa fazer bem pelo menos algumas coisas.
Dados multimodais precisam ser de primeira classe
Texto, imagens, áudio, vídeo, embeddings, logs e traces não devem ficar espalhados por uma tabela relacional, uma coluna vetorial, um bucket de objetos e vários índices paralelos. Eles precisam viver em um único sistema lógico onde recuperação, filtragem, ranqueamento e governança possam acontecer juntos.
A parte difícil não é armazenar esses ativos. A parte difícil é torná-los consultáveis em conjunto sem transformar a arquitetura em mais um problema de pipeline.
A elasticidade precisa partir da carga de trabalho
O tráfego de agentes é irregular. Um sistema pode ficar silencioso por uma hora e então receber uma enxurrada de solicitações de recuperação, memória e uso de ferramentas. O data lake ou object store deve se tornar a base durável: barata, confiável e desacoplada da computação.
Mas a computação não deve continuar cara apenas porque o corpus existe. Se ninguém está pesquisando, o sistema deve gastar muito pouco. Se uma carga de trabalho desperta, a computação deve chegar rapidamente. Nesse mundo, a unidade natural de precificação nem sempre é um cluster permanente. Pode ser a consulta, a sessão ou o minuto de computação ativa.
A multi-tenancy precisa avançar para o nível do agente
Sistemas multi-tenant tradicionais muitas vezes assumem um número gerenciável de grandes tenants. Sistemas agênticos podem criar milhões ou bilhões de estados minúsculos, de curta duração e isolados. Cada agente pode carregar sua própria memória, permissões, traces, branches temporários e caminhos de escrita.
Um design criado para milhares de grandes tenants terá dificuldade quando o tenant se tornar a própria execução do agente.
Branching e rollback se tornam recursos centrais de banco de dados
Agentes vão escrever a coisa errada. Isso não é um caso extremo. Faz parte da carga de trabalho.
Uma camada de dados de IA útil precisa de branching semelhante ao Git e rollback rápido para o estado dos dados. Uma execução de agente deve poder bifurcar um branch de trabalho, testar uma ação, escrever estado temporário e descartá-lo ou promovê-lo. Se uma atualização ruim chegar, o sistema deve ser capaz de retornar rapidamente a um ponto bom conhecido.
Versionamento não é mais apenas uma conveniência analítica. Torna-se um mecanismo operacional de segurança.
Trace e replay determinístico são obrigatórios
Quando um agente falha, a questão não é apenas “qual foi a resposta final?” É “o que o agente viu, recuperou, classificou, decidiu, chamou e escreveu?”
Isso requer um rastreamento de cada etapa significativa. Mais importante ainda, requer reprodução. O sistema deve ser capaz de reconstruir o contexto de decisão como ele existia naquele momento, não como ele aparece depois que um documento foi alterado ou um índice foi reconstruído.
Para agentes, auditabilidade e depurabilidade convergem para o mesmo requisito.
As permissões precisam governar ações, não apenas linhas
A autorização tradicional pergunta quem pode ler uma tabela, uma coluna ou uma linha. Sistemas agênticos precisam de uma pergunta mais dinâmica: o que este agente tem permissão para recuperar, chamar, modificar, divulgar e gastar nesta etapa específica?
A parte difícil se desloca do caminho de leitura para o caminho de ação. A aplicação de políticas precisa acontecer enquanto o agente está em execução, não apenas quando um humano abre um dashboard.
As operações precisam se tornar autônomas
A escala em nível de agente quebra a infraestrutura operada por humanos. Nenhuma equipe consegue gerenciar manualmente índices, compactação, aquecimento de cache, posicionamento de tenants, recuperação e agendamento de recursos em milhões de cargas de trabalho pequenas e em rápida movimentação.
O sistema precisa operar a si mesmo. Caso contrário, a arquitetura pode funcionar em um diagrama, mas falhar no único lugar que importa: produção.
SQL não é suficiente como interface final
Há mais uma questão sobre a qual penso cada vez mais: a própria interface.
SQL foi a interface certa para a era dos analistas. Ainda é essencial. Mas, para empresas construídas em torno de bancos de dados e analytics, SQL também pode se tornar uma forma de dependência de trajetória. A superfície do produto, o modelo de usuário e até a organização muitas vezes presumem que o usuário principal é alguém que sabe escrever uma consulta.
A interface final para dados na era da IA não será um editor de SQL um pouco melhor. Também não será um chatbot colado na frente do banco de dados.
O ponto final mais interessante é um sistema de dados headless, nativo em linguagem natural: um em que uma pessoa ou um agente possa declarar diretamente a intenção e o sistema possa responder, agir ou preparar o plano de execução correto sem expor cada etapa interna como um exercício de escrita de consultas.
Mas isso precisa ser nativo ao banco de dados, não um agente separado posicionado à frente dele.
Se a linguagem natural for apenas uma camada de aplicação, o sistema reintroduz exatamente as costuras que está tentando remover: mais uma etapa de tradução, mais uma janela de contexto desatualizada, mais uma lacuna de governança. O próprio banco de dados precisa entender a pergunta, os dados, as políticas e o caminho de execução.
Isso é muito mais difícil do que construir uma interface amigável. Significa que o banco de dados precisa assumir a propriedade da semântica.
O fosso competitivo que ainda importa
Não tenho uma conclusão perfeitamente limpa. Talvez isso seja apropriado. O mercado está se movendo rápido demais, e muitas suposições antigas estão sendo drenadas mais rápido do que o esperado.
Um dialeto de consulta proprietário não é mais o fosso competitivo que costumava ser. O custo de migração é mais fraco quando agentes conseguem reescrever código de integração. Uma UI familiar importa menos quando o próximo usuário talvez não seja humano. Até a vantagem silenciosa de simplesmente possuir os dados é mais fraca quando formatos de tabela abertos, interfaces em linguagem natural e agentes que usam ferramentas tornam a movimentação mais fácil.
O fosso competitivo em que ainda acredito é menos glamouroso: a capacidade de criar valor real para o usuário ao longo de um longo período, paciente e repetidamente.
É por isso que saí do Summit levando a Databricks a sério. Acho que a Databricks tem uma chance real de se tornar a próxima empresa de um trilhão de dólares em dados. Não porque todo anúncio de produto seja a resposta final. Alguns deles vão mudar. Alguns provavelmente estarão errados. Isso é normal. O que importa é que a empresa continua caminhando de volta em direção ao problema certo.
E o problema certo já não é apenas analytics, data warehousing ou armazenamento transacional. É a fundação de dados para sistemas de IA que agem.
Do lado da Zilliz, temos chegado a uma conclusão semelhante por outro caminho. Os bancos de dados vetoriais não estão desaparecendo. Eles estão se tornando o mecanismo de serving dentro de uma arquitetura mais ampla para dados não estruturados e multimodais. É por isso que pensamos em termos de Vector Lakebase: não como um substituto para bancos de dados vetoriais, mas como a próxima arquitetura construída em torno deles à medida que as cargas de trabalho de IA se tornam mais contínuas, elásticas e agênticas.
O mapa não está concluído. Essa é a melhor parte.
Barato vence caro. Confiável vence não confiável. Cuidadoso vence descuidado. Paciente vence impaciente.
O banco de dados nativo de IA ainda está sendo desenhado. Para todos que estão construindo neste espaço, isso é uma notícia muito boa.
Mais uma coisa: Zilliz Vector Lakebase está disponível em prévia pública
Lançamos a prévia pública do Zilliz Vector Lakebase — uma grande evolução do Zilliz Cloud de um banco de dados vetorial puro para uma base de dados nativa de lake para IA, combinando serving vetorial de baixa latência com a abertura, a escalabilidade e a economia de um data lake.
Principais recursos do Zilliz Vector Lakebase:
- Serving em camadas otimizado para diferentes compromissos entre desempenho em tempo real e custo
- Busca sob demanda para cargas de trabalho em larga escala ou exploratórias sem computação sempre ativa
- Busca em data lake externo — indexe e pesquise diretamente sobre seus dados existentes no lake
- Busca de espectro completo em vetores, texto, JSON e dados geoespaciais com recuperação híbrida e reranking
- Armazenamento unificado nativo de lake construído sobre Vortex, um formato aberto com leituras aleatórias mais rápidas e baratas que Lance ou Parquet
Se sua stack atual separa serving e descoberta em sistemas distintos, vale a pena dar uma olhada no Vector Lakebase. Experimente no Zilliz Cloud — novos cadastros com email profissional recebem US$100 em créditos gratuitos — ou fale conosco sobre seu caso de uso.
Continue lendo
A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud
Milvus 2.6 marks a shift from “vector search + glue code” to a more advanced retrieval engine, and it is now Generally Available (GA) on Zilliz Cloud (a managed Milvus service).
Introducing Business Critical Plan: Enterprise-Grade Security and Compliance for Mission-Critical AI Applications
Discover Zilliz Cloud’s Business Critical Plan—offering advanced security, compliance, and uptime for mission-critical AI and vector database workloads.
Creating Collections in Zilliz Cloud Just Got Way Easier
We've enhanced the entire collection creation experience to bring advanced capabilities directly into the interface, making it faster and easier to build production-ready schemas without switching tools.