Mirroring no Fabric: replicar bancos sem ETL

Quando o pipeline de ETL vira o gargalo do projeto#

Todo time de dados conhece a rotina: para analisar o dado que vive no banco operacional, alguém monta um pipeline de ETL. Extrai do Azure SQL Database ou do Snowflake, transforma, carrega em uma camada analítica, agenda a atualização, monitora a janela noturna e corre atrás quando a carga falha às três da manhã. Esse pipeline funciona, mas custa caro em horas de manutenção e sempre entrega o dado com atraso: o relatório da diretoria mostra o estoque de ontem, não o de agora. O Mirroring no Fabric nasceu para atacar exatamente esse ponto, oferecendo uma forma de trazer o dado operacional para dentro do ambiente analítico quase em tempo real e sem construir o pipeline tradicional.

A ideia é direta. Em vez de você escrever a lógica de extração e carga, o próprio Fabric mantém uma réplica do seu banco externo dentro do OneLake, atualizada de forma contínua. Essa cópia fica em formato Delta, o mesmo padrão aberto que o Fabric usa para tudo, e pode ser consultada e combinada com outros dados como se fosse uma tabela nativa da plataforma. Neste artigo eu explico como isso funciona, para quais cenários vale a pena, onde estão os limites reais e em quais situações o ETL de sempre ainda é a escolha certa.

O Mirroring no Fabric replica o banco, ele não roda um pipeline#

Vale começar desfazendo a confusão mais comum. Mirroring não é uma nova ferramenta de ETL mais fácil de usar. É uma tecnologia de replicação. A diferença é conceitual e muda como você projeta a solução.

Quando você habilita o Mirroring para um banco, o Fabric faz uma cópia inicial completa das tabelas escolhidas e, a partir daí, acompanha as mudanças na origem de forma contínua. Inserções, atualizações e exclusões que acontecem no banco operacional são propagadas para a réplica no OneLake com poucos minutos de defasagem. Por baixo, o mecanismo lê o log de transações ou o fluxo de mudanças da origem, dependendo do tipo de banco, e aplica essas mudanças na cópia Delta. Você não escreve nenhuma linha de transformação para que isso aconteça.

O resultado é uma tabela Delta viva dentro do seu workspace. Ela aparece no Lakehouse, responde ao SQL analytics endpoint, alimenta o Power BI via Direct Lake e pode ser cruzada com dados de outras fontes em uma consulta só. Do ponto de vista de quem consome, é dado do Fabric. Do ponto de vista de quem administra, é uma réplica que se mantém sozinha.

As fontes suportadas cobrem os bancos mais presentes no mercado brasileiro. Os principais hoje são:

Fonte de origem	Natureza do banco	Uso típico que se beneficia
Azure SQL Database	Relacional gerenciado na nuvem	Sistema transacional de ERP, vendas, cadastro
Azure SQL Managed Instance	Relacional gerenciado compatível com SQL Server	Cargas legadas migradas para a nuvem
Snowflake	Data warehouse em nuvem	Dado já consolidado que precisa entrar no ecossistema Fabric
Azure Cosmos DB	NoSQL de documentos, baixa latência	Aplicações modernas, catálogos, perfis, eventos
Azure Database for PostgreSQL	Relacional open source gerenciado	Aplicações web e produtos digitais

A lista cresce a cada trimestre, então confirme sempre o estado atual na documentação da Microsoft antes de fechar uma arquitetura. O que não muda é a natureza da coisa: você conecta a origem, escolhe as tabelas e o Fabric cuida da réplica.

Como o Mirroring funciona por baixo do capô#

Para decidir bem, o consultor precisa entender o mecanismo, não só o botão. O fluxo tem três etapas que vale conhecer.

Primeiro vem a carga inicial. Ao habilitar o Mirroring, o Fabric faz um snapshot das tabelas selecionadas e materializa tudo em Delta no OneLake. Dependendo do volume, essa primeira cópia leva de minutos a algumas horas. É a fase mais pesada, mas acontece uma única vez.

Depois entra a replicação contínua. A partir do snapshot, o Fabric passa a capturar as mudanças da origem, o famoso change data capture, e aplica essas mudanças na réplica de forma incremental. Como só o delta de mudanças trafega, o custo de manter a cópia atualizada é baixo e a defasagem fica na casa de minutos na maioria dos cenários. A origem continua servindo a aplicação normalmente, porque a leitura de mudanças é leve e não concorre com as transações do sistema.

Por fim, a consulta. A réplica Delta fica disponível através de um SQL analytics endpoint somente leitura, e o Power BI a acessa via Direct Lake, sem importar nada e sem recriar cópia. Você combina a tabela replicada com dimensões do seu Lakehouse, com dados de outra fonte espelhada e com o que já existe no ambiente, tudo em uma consulta única. É aqui que o Mirroring mostra o valor: o dado operacional deixa de ser uma ilha e passa a conversar com o resto do modelo analítico.

Um detalhe importante de custo. O armazenamento da réplica espelhada tem uma franquia gratuita atrelada à sua capacidade Fabric, o que torna o Mirroring atraente para quem já paga a capacidade. Isso não significa custo zero, e a conta muda conforme volume e número de fontes, mas o modelo é bem mais previsível do que manter uma frota de pipelines rodando de madrugada.

Onde o Mirroring no Fabric realmente compensa#

Nem todo problema de dados pede replicação. O Mirroring brilha em um conjunto específico de cenários, e reconhecê-los é o que separa uma arquitetura enxuta de uma solução inflada.

O caso mais forte é analytics sobre dado operacional sem sobrecarregar a origem. Quando a diretoria quer acompanhar vendas, estoque ou pedidos com poucos minutos de defasagem, a saída antiga era consultar o banco de produção direto, o que degrada o sistema, ou montar um pipeline com atraso de horas. O Mirroring resolve os dois: o dado chega quase em tempo real e a carga analítica roda sobre a réplica no OneLake, não sobre o banco que atende os clientes.

O segundo caso é unificar fontes dispersas para um modelo único. Muita empresa tem o transacional no Azure SQL, o histórico consolidado no Snowflake e os eventos de produto no Cosmos DB. Espelhar as três para o OneLake permite construir um modelo semântico que cruza tudo sem mover dado manualmente entre plataformas. O trabalho de engenharia que sobra é a modelagem, não a tubulação.

O terceiro é acelerar a entrega inicial de um projeto. Em vez de gastar as primeiras semanas construindo pipelines de ingestão, o time espelha as fontes, ganha o dado dentro do Fabric em horas e parte direto para a camada de valor, que é a modelagem e os relatórios. Para quem precisa mostrar resultado rápido, isso encurta o caminho até o primeiro dashboard útil.

A tabela abaixo resume a decisão entre replicar e construir pipeline conforme o objetivo:

Objetivo	Melhor caminho	Por quê
Espelhar tabelas quase em tempo real	Mirroring	Réplica contínua, sem pipeline para manter
Reduzir carga no banco de produção	Mirroring	Analytics roda sobre a cópia no OneLake
Unir várias fontes no OneLake	Mirroring	Cada fonte vira tabela Delta consultável
Limpar, enriquecer e agregar dado bruto	Pipeline de ETL	Transformação pesada exige lógica própria
Aplicar regras de negócio complexas	Pipeline de ETL	Mirroring copia, não transforma
Ingerir arquivos, APIs e formatos variados	Pipeline de ETL	Fora do escopo de replicação de banco

Os limites que você precisa conhecer antes de prometer#

Aqui entra a parte honesta, a que costuma faltar nos textos de fornecedor. O Mirroring é poderoso dentro do escopo dele, e frágil fora dele. Prometer o que a ferramenta não faz é o caminho mais curto para um projeto frustrado.

O primeiro limite é o mais fundamental: Mirroring replica, não transforma. A tabela que chega no OneLake é um espelho da origem, com a mesma estrutura, os mesmos nomes técnicos e a mesma bagunça que existir lá. Campos mal nomeados, datas inconsistentes, valores nulos onde não deveriam e chaves que ninguém documentou vêm todos junto. A limpeza, a padronização e o enriquecimento continuam sendo trabalho seu, feito depois, sobre a réplica.

O segundo é o escopo de fontes. Mirroring funciona para os bancos suportados, e só. Ele não substitui a ingestão de arquivos CSV e Parquet, de APIs REST, de planilhas de SharePoint ou de sistemas legados sem um conector de replicação. Para tudo isso, você ainda precisa de um pipeline, e o Data Factory no Fabric continua sendo a ferramenta certa.

O terceiro ponto são as restrições técnicas de cada fonte. Existem tipos de dados que não são replicados, tabelas sem chave primária que ficam de fora, colunas com estruturas específicas que não passam, e limites de quantas tabelas você espelha por banco. Cada origem tem sua própria lista de exceções, e essa lista muda conforme o produto evolui. Nunca desenhe a solução assumindo que cem por cento das tabelas vão espelhar sem atrito. Valide antes.

O quarto é a natureza somente leitura da réplica. Você consulta a cópia, não escreve nela. Se o seu caso exige gravar de volta na origem a partir do Fabric, o Mirroring não é o mecanismo. Ele foi feito para o fluxo no sentido da análise, do sistema operacional para o ambiente analítico.

Resumindo o critério prático: se o que você precisa é a mesma tabela, atualizada, do outro lado, o Mirroring resolve com elegância. Se você precisa de uma tabela diferente da origem, com regras aplicadas, o pipeline continua no jogo. Na maioria dos projetos maduros, os dois convivem: o Mirroring traz o dado bruto quase em tempo real e a engenharia de dados constrói as camadas de valor por cima.

Mirroring e ETL não competem, eles se complementam#

O erro de leitura mais comum é tratar o Mirroring como substituto do ETL. Na prática, a arquitetura mais sólida usa os dois em papéis distintos. O Mirroring cuida da ingestão de bancos suportados, entregando réplicas Delta atualizadas sem esforço de manutenção. O pipeline cuida do resto: fontes fora do escopo, transformação pesada, regras de negócio e as camadas prata e ouro do modelo.

Pense nas camadas de um Lakehouse. A camada bronze, de dado bruto, é candidata natural ao Mirroring quando a origem é um banco suportado. As camadas prata e ouro, onde o dado é limpo, conformado e agregado para consumo, continuam sendo construídas com transformação explícita. Quem quiser aprofundar essa organização em camadas encontra o detalhamento no nosso guia prático de Lakehouse no Fabric, e o panorama de estratégia está em Microsoft Fabric: o que é e vale a pena em 2026.

O ganho concreto de combinar os dois é reduzir superfície de manutenção. Cada pipeline que você não precisa escrever é um ponto a menos que falha e algumas horas por mês que a equipe usa para gerar valor em vez de apagar incêndio. Quando aplicado no lugar certo, o Mirroring corta trabalho repetitivo sem esconder complexidade debaixo do tapete.

Perguntas frequentes#

O Mirroring no Fabric substitui completamente o ETL? Não. Ele substitui o pipeline de ingestão apenas para os bancos suportados e apenas quando você quer a réplica fiel da origem. Toda transformação, limpeza e aplicação de regra de negócio continua exigindo trabalho, feito sobre a cópia Delta. Ingestão de arquivos, APIs e fontes fora da lista de replicação também segue precisando de pipeline. Mirroring e ETL convivem, cada um no seu papel.

Quanto tempo de defasagem existe entre a origem e a réplica? Na maioria dos cenários, a defasagem fica na casa de minutos após a carga inicial, porque o Fabric captura e aplica as mudanças de forma incremental. Não é replicação síncrona de milissegundos, então não use o Mirroring para casos que exigem consistência transacional exata no mesmo instante. Para analytics quase em tempo real, o atraso é perfeitamente aceitável.

O Mirroring sobrecarrega o banco de produção? O impacto na origem é baixo, porque o mecanismo lê o fluxo de mudanças, o change data capture, em vez de rodar consultas pesadas repetidas. Depois da carga inicial, que é o momento de maior esforço, a replicação contínua trafega só o delta de alterações. É justamente por isso que o Mirroring é uma boa saída para tirar a carga analítica de cima do sistema transacional.

Preciso escrever código para configurar o Mirroring? Não para a replicação em si. A configuração é feita pela interface do Fabric: você conecta a origem, autentica, escolhe as tabelas e habilita. O código entra depois, na camada de transformação e modelagem que você constrói sobre a réplica, e no Power BI que consome o modelo. A tubulação de ingestão é o que deixa de existir.

Quais bancos posso espelhar hoje? Os principais suportados incluem Azure SQL Database, Azure SQL Managed Instance, Snowflake, Azure Cosmos DB e Azure Database for PostgreSQL, entre outros que entram no catálogo a cada trimestre. A lista evolui rápido, então confirme sempre o estado atual na documentação oficial antes de fechar a arquitetura. O conceito é estável, a cobertura de fontes é o que cresce.

A réplica no OneLake serve para o Power BI direto? Sim. A cópia fica em formato Delta e é exposta por um SQL analytics endpoint, o que permite ao Power BI consumir via Direct Lake, sem importar nem duplicar o dado de novo. Você monta o modelo semântico sobre a réplica, cruza com outras tabelas do Lakehouse e publica os relatórios normalmente. Quem quiser estruturar bem essa camada de visualização pode se apoiar no nosso trabalho de Power BI.

O caminho curto quando ele existe de verdade#

O Mirroring no Fabric é uma daquelas tecnologias que resolvem um problema real sem cobrar o preço de sempre. Quando a origem é um banco suportado e você quer a réplica fiel, atualizada e consultável, ele corta semanas de trabalho de pipeline e entrega o dado operacional dentro do ambiente analítico com defasagem de minutos. Fora desse escopo, o ETL continua sendo a ferramenta certa, e a arquitetura madura usa os dois juntos. O segredo é saber qual caminho pede cada dado, e é aí que a experiência de quem já montou dezenas de ambientes faz diferença.

Se a sua empresa está avaliando o Fabric e quer desenhar a arquitetura de dados sem cair na armadilha do pipeline desnecessário nem prometer o que a replicação não entrega, fale com a gente. A Fynx ajuda a decidir onde o Mirroring economiza esforço e onde o ETL ainda é indispensável.