O SaaSpocalypse tem um problema de dados que ninguém está discutindo
Em 3 de fevereiro de 2026, aproximadamente $285 bilhões em valor de mercado evaporaram de empresas globais de SaaS e serviços de TI em uma única sessão de negociação. O relatório Retool 2026 Build vs. Buy confirmou a tendência subjacente: 35% das empresas já substituíram pelo menos uma ferramenta SaaS por uma solução customizada, e 78% planejam construir mais. A Gartner prevê que, até 2030, 35% das ferramentas SaaS pontuais serão substituídas por agentes de IA.
A tendência é real. A economia de construir softwares customizados mudou. Como a TechCrunch colocou: “agora, graças a agentes de código, as barreiras de entrada para criar software estão tão baixas que a decisão entre construir ou comprar está migrando para construir.”
Mas essa conversa está presa na pergunta errada. A maior parte das discussões sobre o SaaSpocalypse focam no que substituir e na velocidade com que a IA consegue construir. Ninguém está perguntando onde essas substituições devem existir.
Essa é uma pergunta decisiva, porque a resposta define se as empresas vão escapar da armadilha do SaaS ou apenas cair em algo pior. Sem uma base de dados compartilhada, o cenário mais provável é a proliferação de centenas de microaplicações criadas com IA, cada uma com seu próprio banco de dados, sua própria definição de cliente e suas próprias falhas de governança. Isso não representa uma saída dos silos de SaaS, mas a reconstrução desses silos em uma versão ainda mais desorganizada.
Adotar a abordagem errada pode ter um custo alto. A Gartner estima que a baixa qualidade de dados custa, em média, $12,9 milhões por ano às organizações. Quando empresas constroem sem uma base de dados unificada ou governança adequada, esse custo cresce com retrabalho, inconsistências e complexidade operacional.
De certa forma, já vimos isso antes na era do Modern Data Stack. Com o objetivo de “eliminar a plataforma monolítica de dados”, equipes passaram a usar dezenas ou até centenas de ferramentas extremamente específicas, criando um novo problema de governança e complexidade de gestão. A Databricks resolveu grande parte disso ao unificar essas ferramentas em uma única plataforma. Agora, busca resolver um problema semelhante no software como um todo.
O SaaSpocalypse explica por que construir. Este artigo trata de onde.
A promessa: uma camada de dados para governar todas
A ideia é simples: em vez de adotar softwares empresariais de vários fornecedores, cada um com seu próprio banco de dados, modelo de dados e pipeline de extração, a empresa passa a desenvolver aplicações customizadas sobre uma camada de dados comum que já pertence à organização.
Já auditei uma empresa que operava com cinco ferramentas diferentes de BI. Cada uma tinha seu próprio pipeline de dados, sua própria definição de receita e sua própria cadência de atualização. O problema não estava nos fornecedores de SaaS, mas na ausência de uma camada de dados compartilhada. No fim, cada ferramenta se tornava uma ilha de dados que precisava ser reconciliada com todas as outras.
Esse é o imposto do ETL. Cada fornecedor de SaaS adiciona um custo de integração que não aparece na fatura: o pipeline de extração, o mapeamento de schemas para padronização, a lógica de reconciliação e o SLA necessário para manter tudo atualizado. Em oito anos construindo plataformas de dados, nunca vi uma empresa mensurar esse custo com precisão. Na prática, ele quase sempre supera o valor da assinatura. E o problema se agrava quando consideramos que grandes empresas operam, em média, mais de 1.000 aplicações!
Os sinais de que esse custo pode deixar de ser inevitável já são concretos. A SAP anunciou o compartilhamento de dados zero-copy com as principais plataformas de dados, com disponibilidade geral prevista para o primeiro trimestre de 2026. A Workday lançou o Data Connect, que viabiliza o compartilhamento bidirecional zero-copy por meio do Apache Iceberg. A direção é clara: os próprios fornecedores de SaaS já reconhecem que os dados devem estar na sua plataforma, e não confinados dentro do produto deles. Esse é exatamente o posicionamento que a Databricks defende com sua proposta de plataforma aberta.
Essa convergência só se torna possível porque o lakehouse foi construído sobre formatos e protocolos abertos. Delta Lake, Apache Iceberg e Delta Sharing são tecnologias open source, o que significa que a camada de dados não fica sob o controle de um único fornecedor. É justamente essa abertura que torna o modelo zero-copy viável do ponto de vista arquitetural. Um data warehouse proprietário dificilmente consegue atuar como base neutra para aplicações. Um lakehouse aberto, sim.
Se os seus dados já estão em um lakehouse, e os fornecedores de SaaS já começam a compartilhá-los com essa camada por meio de zero-copy, a pergunta passa a ser outra: por que não desenvolver aplicações diretamente sobre essa base?
O que falta em uma plataforma de dados (e o que o Lakebase muda)
A resposta para “por que não” é que uma plataforma analítica não é uma plataforma de aplicações. Ter um lakehouse não significa, por si só, que ele está pronto para suportar software empresarial. Para isso, ainda são necessárias cinco capacidades essenciais:
- Gravações transacionais com garantias ACID. Plataformas analíticas são otimizadas para leitura, com ingestão append-only, transformações em batch e consultas analíticas. Já as aplicações empresariais precisam inserir, atualizar e excluir registros individuais com consistência transacional total. Delta Lake e Iceberg suportam escritas analíticas, mas não foram projetados para o tipo de transação de alta frequência e baixa latência que um CRM ou sistema de tickets exige.
- Latência abaixo de um segundo para interfaces interativas. Um dashboard levar três segundos para atualizar pode ser aceitável. Um formulário levar esse mesmo tempo para ser enviado, não. Workloads de aplicação exigem uma camada de serving com latência baixa e consistente, algo que data warehouses orientados a batch não conseguem garantir.
- Segurança em nível de linha e coluna vinculada aos papéis da aplicação. Governança analítica, que define quem pode consultar determinadas tabelas, não é a mesma coisa que segurança de aplicação, que define quais registros cada usuário pode ver dentro de uma tabela, de acordo com seu papel no sistema. Isso exige um controle de acesso mais granular, integrado à autenticação da aplicação.
- Arquitetura orientada a eventos para mudanças de estado em tempo real. Aplicações reagem a eventos o tempo todo: um ticket é atribuído, uma oportunidade avança de etapa, uma aprovação é concedida. Pipelines em batch, atualizados a cada 15 minutos ou a cada hora, não conseguem sustentar esse tipo de operação. Para isso, é preciso contar com captura de mudanças, streaming ou barramentos de eventos.
- Uma experiência de desenvolvimento que não dependa de engenharia de dados a cada mudança. Se adicionar um novo campo em um formulário exige que um engenheiro de dados altere o schema de uma tabela Delta, rode uma migração e atualize um pipeline de transformação, a velocidade de desenvolvimento simplesmente desaba.
Já vi equipes criarem ferramentas internas sobre o data warehouse e só depois perceberem que uma camada analítica atualizada em batch não consegue sustentar uma aplicação interativa. As consultas até funcionavam bem para dashboards, mas eram lentas demais para ações simples, como enviar um formulário. A distância entre uma estrutura pronta para analytics e uma estrutura pronta para aplicações costuma ser maior do que a maioria das equipes imagina.
É nesse ponto que o Databricks Lakebase muda a lógica. Descrito por seus criadores como o que você construiria hoje se precisasse redesenhar os bancos OLTP do zero, o Lakebase é uma arquitetura de banco de dados de terceira geração que roda uma camada de computação Postgres serverless, totalmente gerenciada, sobre armazenamento de objetos em nuvem com formatos abertos. Ele oferece escritas transacionais com garantias ACID no lake, computação com latência abaixo de um segundo que escala até zero, ramificações de bancos de dados em escala de petabytes em um modelo semelhante ao Git e, de forma crítica, a unificação de OLTP e OLAP na mesma camada de armazenamento.
Esse último ponto é o mais importante para este argumento. Quando workloads transacionais e analíticos compartilham o mesmo armazenamento, o ETL entre eles deixa de existir. A aplicação escreve os dados, e a camada analítica os lê. Sem pipeline. Sem mapeamento de schema. Sem reconciliação. Sem SLA de atualização. Zero-copy por definição. Na prática, isso significa que o time financeiro deixa de esperar dias para trabalhar com números de receita já reconciliados.
O Lakebase resolve dois dos desafios mais difíceis: escritas transacionais e latência de serving, que antes eram barreiras arquitetônicas importantes. Mas ele não resolve tudo sozinho. A Databricks Intelligence Platform, de forma mais ampla, cobre os outros pontos com capacidades complementares. O Unity Catalog oferece segurança em nível de linha e coluna com controles de acesso baseados em atributos, ampliando a governança de analytics para workloads de aplicação. Structured Streaming e Delta Live Tables viabilizam arquiteturas orientadas a eventos com captura nativa de mudanças. Já o Databricks Apps permite que desenvolvedores criem e publiquem aplicações diretamente na plataforma, sem depender de engenharia de dados a cada ajuste. Nenhum produto resolve os cinco pontos de uma vez. Mas, quando olhamos para a plataforma como um todo, já existe um caminho sólido para cada um deles, e esse caminho está mais avançado do que muitas empresas ainda percebem.
Modelo de maturidade: Cinco níveis, dos silos de SaaS à plataforma de aplicações
Nem toda empresa deve tentar fazer essa transição, e nenhuma deveria tentar fazer tudo de uma vez. Esse é um processo gradual, em que cada etapa exige pré-requisitos específicos antes do próximo avanço.
Nível 0 – SaaS em silos, ETL para tudo. Cada ferramenta SaaS mantém seus próprios dados. A empresa extrai o que consegue via API ou arquivos, carrega esse material em um data warehouse e depois o transforma para análise. É assim que a maioria das empresas ainda opera. Nesse estágio, o custo de ETL é o mais alto, mas o risco operacional é o menor, porque cada aplicação continua sob responsabilidade do fornecedor.
Nível 1 – Analytics com zero-copy. Os fornecedores de SaaS passam a compartilhar dados com a sua plataforma por meio de integrações zero-copy, como Iceberg e Delta Sharing. Com isso, você deixa de construir pipelines de extração para parte dessas ferramentas. A análise melhora porque os dados ficam mais atualizados e consistentes. Ainda não se trata de construir aplicações, mas de eliminar o custo de ETL no lado da leitura.
Nível 2 – Aplicações customizadas com foco em leitura. A empresa começa a desenvolver aplicações leves que consomem dados da plataforma, como portais para clientes, dashboards operacionais, ferramentas internas de reporte e interfaces de busca. São aplicações de leitura ou majoritariamente de leitura. Elas não exigem escritas transacionais no lakehouse. É nesse nível que se encaixa a maior parte dos casos de substituição de SaaS citados no relatório da Retool.
Nível 3 – Aplicações customizadas de leitura e escrita. Aqui, a empresa passa a desenvolver aplicações que tanto leem quanto escrevem na plataforma de dados, como um CRM simplificado, um sistema interno de tickets ou um fluxo de aprovação customizado. Esse estágio exige capacidades transacionais, como Lakebase ou equivalente, além de segurança em nível de aplicação e uma experiência de desenvolvimento realmente robusta. Nesse nível, a empresa substitui funções específicas de SaaS, não plataformas inteiras.
Nível 4 – Plataforma completa de aplicações. A plataforma de dados se torna a base de todo o software empresarial customizado. Bancos operacionais, workloads analíticos e modelos de IA ou machine learning passam a compartilhar a mesma camada de armazenamento. Novas aplicações passam a ser construídas diretamente sobre essa base. O SaaS fica reservado para áreas em que a especialização do fornecedor continua difícil de substituir, como folha de pagamento ou cálculo tributário.
A maioria das empresas com as quais trabalho acredita estar pronta para o nível 3 ou 4. Quando auditamos a plataforma de dados, porém, elas normalmente estão bem posicionadas no nível 1, e isso não é uma crítica. Um nível 1 bem executado gera mais valor do que um nível 4 mal implementado.
Os pré-requisitos de cada etapa não são apenas técnicos. O nível 2 exige um time capaz de desenvolver e manter aplicações web, e não apenas pipelines de dados. O nível 3 exige domínio de segurança de aplicações, operação contínua e pipelines de CI/CD para código de aplicação. Já o nível 4 exige uma equipe interna de engenharia de plataforma que trate a camada de dados como um produto, com SLAs, documentação e suporte para desenvolvedores.
O acelerador de IA (e seus limites)
O desenvolvimento assistido por IA é o principal motivo pelo qual a lógica entre construir e comprar mudou. A Gartner estima que, até 2028, 90% dos engenheiros de software corporativo vão usar assistentes de código com IA, frente a menos de 14% em 2024. Na prática, essas ferramentas podem acelerar o desenvolvimento de aplicações de 3 a 5 vezes. Isso significa que uma ferramenta interna customizada, que antes exigia seis meses de trabalho e um time dedicado, agora pode ganhar um protótipo funcional em poucas semanas.
Isso muda a economia. Mas não muda a arquitetura.
Agentes de código com IA resolvem a pergunta conseguimos construir rápido o suficiente? O que eles não resolvem é outra pergunta, muito mais crítica: conseguimos operar isso com confiabilidade? O risco aqui é claro e previsível. Um time usa um agente de IA para criar, em um fim de semana, um substituto para um CRM. A solução funciona. Consulta o lakehouse, renderiza a interface e até executa operações básicas de CRUD. Só que, no terceiro mês, os problemas começam a aparecer. Um gestor pergunta por que não consegue ver um registro de cliente que outro time consegue acessar. Alguém percebe que não existe trilha de auditoria para mostrar quem alterou o quê. Uma revisão de compliance revela que registros supostamente excluídos continuam existindo, apenas escondidos na interface.
Esses cenários não são hipotéticos. São exatamente os tipos de falha que fornecedores de SaaS corporativo passaram décadas aprendendo a resolver, e que aplicações criadas às pressas com IA tendem a ignorar por completo.
A forma mais correta de enxergar esse movimento é esta: o desenvolvimento assistido por IA é um viabilizador econômico, não arquitetural. Ele torna a construção mais viável. Não torna a boa construção automática. O modelo de maturidade continua valendo. A IA encurta o tempo necessário em cada etapa, mas não elimina a necessidade de passar por elas.
Quem deve tentar fazer isso (e quem não deve)
Antes de uma empresa considerar, de fato, construir aplicações sobre sua plataforma de dados, três condições precisam estar presentes.
A plataforma de dados já precisa ter maturidade. Se o lakehouse ainda está em fase de construção, se a camada de governança continua incompleta ou se a qualidade dos dados ainda é inconsistente, o caminho certo é resolver isso primeiro. Construir aplicações sobre uma base frágil só amplia problemas que já existem. Quando a governança está bem estabelecida, o Unity Catalog controla os acessos, a linhagem está rastreada e a qualidade dos dados é monitorada, o lakehouse passa a fazer sentido como base para aplicações empresariais. O investimento em acertar a camada de dados traz retorno acumulado quando as aplicações passam a consumi-la diretamente.
É preciso existir uma integração com SaaS que realmente doa. Os melhores casos para começar são aqueles em que o imposto de ETL é mais alto, ou seja, situações em que a empresa gasta mais tempo integrando e reconciliando dados do que usando a ferramenta em si. O ponto de partida deve ser um caso específico. Não cinco. Não todos ao mesmo tempo.
O time precisa ser capaz de operar o que constrói. Construir uma aplicação costuma ser a parte mais simples. O difícil é operar isso no dia a dia: monitorar, corrigir, proteger, escalar, atender usuários e lidar com incidentes fora do horário comercial. Se o time de dados ainda nunca operou uma aplicação voltada ao usuário final, o melhor caminho é começar pelo Nível 2, com aplicações focadas em leitura, e ganhar maturidade operacional antes de avançar para o Nível 3.
Se essas três condições já estiverem presentes, o melhor movimento é começar pelo Nível 1, caso a empresa ainda não esteja nele. Ative o compartilhamento zero-copy com os maiores fornecedores de SaaS. Meça a redução do imposto de ETL. Construa uma primeira aplicação focada em leitura sobre a plataforma de dados. Entenda o que funciona, o que quebra e o que precisa evoluir. Só depois disso vale avaliar o Nível 3.
As empresas que tendem a ter sucesso nessa transição são as que tratam esse movimento como uma jornada de maturidade, não como um projeto de migração. As que tendem a falhar são as que leem as manchetes sobre o SaaSpocalypse, entregam um prompt para um agente de código com IA e esperam ter um software enterprise pronto até sexta-feira.
A plataforma de dados pode, sim, se tornar a plataforma de aplicações. Mas o verdadeiro gargalo não está na tecnologia. Está na governança, na maturidade operacional e na disciplina para evoluir de forma incremental. Isso sempre foi verdade, e a IA não muda esse ponto.
Com o Lakebase unificando armazenamento transacional e analítico, o Unity Catalog governando o acesso em todos os workloads e o Mosaic AI sustentando a camada de inteligência, essa arquitetura deixou de ser apenas uma hipótese. Ela já começa a tomar forma em produção, sobre formatos abertos que não ficam sob o controle de um único fornecedor. O gargalo continua sendo governança, maturidade operacional e disciplina para evoluir passo a passo. A diferença é que, pela primeira vez, a plataforma parece estar mais pronta do que muitas organizações. Esse gap está diminuindo. E as empresas que conseguirem fechá-lo primeiro vão ajudar a definir a próxima era do software empresarial.
Sobre a Indicium AI
A Indicium AI conta com a confiança de algumas das maiores empresas do mundo para colocar IA em produção em escala. Somos uma consultoria global AI-native, com experiência comprovada nos setores de serviços financeiros, energia e utilities, saúde e ciências da vida, varejo e bens de consumo, além de manufatura. Da estratégia à implementação e aos resultados de negócio, ajudamos empresas a capturar valor com IA com clareza, velocidade e profundidade técnica.
Com mais de 600 especialistas em IA, atendemos mais de 50 clientes em cinco localidades globais. Trabalhamos lado a lado com parceiros estratégicos, como Anthropic, Databricks, AWS, OpenAI e Microsoft, para entregar IA moderna com agilidade e impacto mensurável.
