Data mesh é a ideia mais citada e menos implantada da engenharia de dados da última década. Quase sete anos depois de o conceito aparecer, a maioria dos times de dados usa o vocabulário (domínio, produto de dados, plataforma self-service) e uma minoria operou a mudança de fato. A diferença entre os dois grupos quase nunca é tecnológica.
Este texto separa o que sobreviveu do que travou, com base na análise de 2026 da Thoughtworks, uma observação qualitativa de projetos de clientes, sem números de adoção. Onde há opinião nossa, dizemos que é nossa.
O que data mesh nunca foi: uma ferramenta
A tese central da própria Thoughtworks é que o mesh é um paradigma sociotécnico: mudar comportamento é mais difícil que mudar ferramenta, e não existe produto de prateleira que o entregue. Isso desmonta o jeito mais comum de começar, que é comprar uma plataforma e esperar que a organização se reorganize em volta dela.
Os quatro princípios continuam de pé, e vale lê-los como perguntas de gestão:
- Propriedade por domínio. Quem produz o dado responde por ele, inclusive pela qualidade.
- Dado como produto. Quem consome é cliente, com expectativa de prazo, formato e suporte.
- Plataforma self-service. Um time central entrega a infraestrutura comum para que domínios não reinventem pipeline.
- Governança federada e computacional. As regras são decididas em conjunto e aplicadas por código, não por reunião.
Data mesh é uma decisão sobre quem responde pelo dado, não sobre onde o dado mora.
O que sobreviveu: produto, contrato e plataforma enxuta
A leitura mais útil do estado atual é a lista do que já virou prática comum, segundo a Thoughtworks: produtos de dados, contratos, definições de SLO/SLA e painéis de qualidade. Nós acrescentamos uma observação própria: o que sobrevive é o que cabe dentro de um time, sem exigir reestruturação da empresa.
Data contracts são o exemplo mais claro. Um contrato versionado entre produtor e consumidor, com schema, SLO de qualidade, termos de uso e política de acesso, entrega o benefício central do mesh (previsibilidade para quem consome) sem pedir que ninguém mude de organograma.
Outro ponto que se consolidou é o modelo híbrido de plataforma: um time central provê o encanamento comum (armazenamento, orquestração, catálogo, observabilidade) e os domínios escolhem as ferramentas da última milha. A central deixa de ser porteiro e vira centro de habilitação. A plataforma, nesse desenho, é tratada como produto interno, com roadmap, usuários e metas de serviço próprias.
O que travou: domínio de fachada e governança por comitê
Os padrões de falha que a Thoughtworks lista são conhecidos de quem já viu o projeto de perto:
- Domínios que são times de TI renomeados, sem mandato nem autoridade de negócio. O organograma mudou, a decisão continua no mesmo lugar.
- Paralisia de análise sobre fronteiras. Mais de um ano mapeando o legado e discutindo limites perfeitos de domínio, quando as fronteiras vão mudar de qualquer jeito.
- Gerente de projeto rebatizado de dono de produto de dados, sem treinamento nem tempo no calendário para o papel.
- Governança por comitê em vez de política codificada.
- Plataforma completa antes de provar valor.
O gargalo mais teimoso, segundo o texto, é o alinhamento entre as áreas: jurídico, compliance, risco e negócio precisam concordar com as políticas antes que elas possam ser automatizadas. Esse trabalho não se terceiriza para a engenharia. É o mesmo problema que aparece quando se tenta tratar governança de dados como código: o código é a parte fácil, a decisão compartilhada é a parte lenta.
Há ainda uma armadilha de desenho: mapear um caso de uso para um produto de dados. O resultado é um catálogo de tabelas descartáveis, sem reuso. A Thoughtworks recomenda um produto de dados enxuto e reutilizável, e adverte que grande demais reconstrói um silo e pequeno demais cria um novo problema de agulha no palheiro.
Por que a IA reabriu a conversa
O motivo pelo qual o tema voltou à pauta de diretoria é prático: agente de IA é um consumidor de dado que não perdoa ambiguidade. A Thoughtworks chama o mesh de pré-requisito de IA confiável e descreve produtos de dados de uso duplo, que servem a analytics e a IA, com saídas que podem ser um endpoint de inferência, um fluxo de eventos, um conjunto de dados pronto para IA ou até um servidor MCP.
A afirmação de que o mesh é o pré-requisito é opinião de uma consultoria que vende o modelo; tomamos como direção, não como lei. Mas o raciocínio por trás dela é sólido: um agente só é tão confiável quanto o contrato do dado que ele consulta. Isso conecta diretamente com o que descrevemos em dado pronto para IA: dado limpo, contextualizado e rastreável, com dono que responde.
Como começar sem implantar o mesh inteiro
Para uma empresa de médio porte, o mesh completo costuma custar mais do que entrega. O que recomendamos, como prática nossa e não como método de mercado, é um começo pequeno e deliberado:
- Escolha um domínio com dor real e dono de negócio disposto, por exemplo comercial ou financeiro. Domínio sem patrocinador de negócio é o caso do domínio de fachada.
- Defina um ou dois produtos de dados, com consumidores nomeados. Se ninguém consome, não é produto.
- Nomeie um dono por produto, com tempo reservado, e escreva o contrato: schema, SLO de frescor e de qualidade, política de acesso e canal de suporte.
- Publique o contrato versionado e meça o uso. Produto que ninguém usa em 90 dias volta para revisão ou é desligado.
- Só então generalize a plataforma, a partir do que os dois primeiros produtos pediram, e não de um diagrama.
O critério de parada também importa: se, depois dos dois primeiros produtos, o ganho de confiança no dado não aparece nas conversas de decisão, o problema está na priorização, e mais estrutura não ajuda.
Perguntas que sempre voltam
Três dúvidas aparecem em quase toda conversa sobre o tema.
O que é data mesh?
Data mesh é uma abordagem sociotécnica em que cada domínio de negócio é dono dos dados que produz, os entrega como produto a quem consome e se apoia em uma plataforma comum com governança aplicada em código. Não é uma ferramenta nem uma arquitetura de armazenamento: é uma forma de distribuir responsabilidade sobre o dado.
Data mesh vale a pena para empresa de médio porte?
Raramente na forma completa. Com poucos domínios e um time de dados pequeno, a coordenação central ainda é mais barata que a federação. O que vale levar do mesh é a parte que cabe em um time: produto de dados com dono, contrato versionado e métrica de uso. Se a empresa crescer em domínios e em consumidores, o desenho pode evoluir a partir dessa base.
Qual a diferença entre data mesh e data lake ou lakehouse?
Lake e lakehouse são escolhas de armazenamento e processamento; mesh é uma escolha de responsabilidade. Um mesh pode rodar sobre um lakehouse, sobre um warehouse ou sobre os dois. A pergunta que o mesh responde é quem é dono de cada conjunto de dados e de sua qualidade, enquanto a de lakehouse é onde e como o dado fica armazenado.