O time descobre que dá para consultar o SQL Server de produção direto do Databricks, sem pipeline, sem janela de carga, sem time de engenharia no caminho. Em duas semanas existem sete foreign catalogs, um dashboard executivo apontando para o banco transacional e um DBA perguntando por que a carga do OLTP dobrou às nove da manhã. Ninguém errou um comando. O que faltou foi decidir o que aquele acesso era: uma exploração ou um sistema em produção. Federação é uma capacidade de arquitetura excelente — e é péssima como estratégia padrão de acesso a dados.

A fronteira real Federar e ingerir não são estratégias concorrentes, são respostas para perguntas diferentes. Federação otimiza tempo até a primeira resposta. Ingestão otimiza custo, latência e previsibilidade da milésima resposta. A decisão não é sobre preferência de ferramenta: é sobre quantas vezes aquela query vai rodar, quem paga o compute e o que acontece quando a fonte cai.

O que é Lakehouse Federation?

Lakehouse Federation é a plataforma de federação de consultas do Databricks. Ela entrega acesso governado e somente leitura a dados externos por meio de foreign catalogs do Unity Catalog, com pushdown automático de consulta e controle de acesso granular no nível da tabela. Você registra dois objetos: uma connection — o objeto securável que guarda caminho e credenciais do sistema externo — e um foreign catalog, que espelha o banco remoto dentro do Unity Catalog. A hierarquia resultante é connection → foreign catalog → schema → table, e a partir daí a tabela remota se comporta como qualquer objeto do catálogo.

O contraste com a alternativa importa. Uma tabela ingerida é uma cópia governada, materializada em Delta, com histórico, otimização de layout e custo de armazenamento. Uma foreign table não é cópia nenhuma: é um ponteiro com contrato de governança. O dado continua onde sempre esteve, e cada consulta é uma viagem à fonte.

Existe ainda uma distinção que muita gente ignora, e ela muda a conta:

• Query federation — as consultas do Unity Catalog são empurradas para o banco externo via JDBC. A query roda no Databricks e no compute remoto. É o modo usado para MySQL, PostgreSQL, Oracle, Teradata, SQL Server, Azure Synapse, Redshift, Snowflake, BigQuery, Salesforce Data 360 e Databricks-to-Databricks.
• Catalog federation — as consultas acessam diretamente as tabelas no object storage, rodando apenas no compute do Databricks. A documentação é explícita: essa modalidade é mais econômica e mais otimizada em performance que a query federation. É o caminho para Hive metastore legado ou externo, Snowflake e OneLake.

Em ambos os casos o acesso é somente leitura. Se você precisa escrever, o caminho é a Spark Data Source API — não a federação.

O problema que resolve

Federação resolve o custo de oportunidade da espera. Antes dela, responder “quantos contratos inadimplentes existem no core bancário?” exigia pipeline, modelagem, janela e aprovação. A documentação da Databricks lista os cenários onde ela é a escolha certa: relatórios sob demanda, prova de conceito, fase exploratória de novos pipelines de ETL ou relatórios e suporte a cargas durante migração incremental.

Repare no que essa lista tem em comum: são cargas de baixa recorrência e alta incerteza. Nenhuma delas diz “dashboard corporativo com trezentos usuários concorrentes”. E a própria documentação fecha a questão quando a fonte suporta as duas opções: “Databricks recommends ingestion using Lakeflow Connect managed connectors because they scale to accommodate high data volumes and lower query latency” — escolha federação para relatórios ad hoc ou trabalho de prova de conceito sobre seus pipelines.

Os quatro erros que eu mais encontro em campo:

1. Federar o OLTP e chamar de camada analítica. Cada refresh de dashboard vira carga no sistema transacional, que não foi dimensionado para scan analítico.
2. Ignorar de quem é o compute. Em query federation, parte do trabalho roda no banco remoto — e essa fatura não aparece no seu painel do Databricks.
3. Assumir pushdown uniforme. O que é empurrado varia por conector e por tipo de compute. Um ILIKE inocente traz a tabela inteira pela rede.
4. Confundir federação com sincronismo garantido. Sim, o dado é vivo. Também é frágil: manutenção, lock ou indisponibilidade na fonte derruba o seu relatório.

Como funciona — passo a passo

1. Classifique a carga antes de escolher a tecnologia. Pergunte quantas vezes por dia a consulta roda, quantos usuários dependem dela e qual o impacto de uma indisponibilidade da fonte. Recorrência alta e criticidade alta apontam para ingestão.
2. Prepare o compute. Federação exige Databricks Runtime 13.3 LTS ou superior com modo de acesso Standard ou Dedicated, ou SQL warehouse Pro/Serverless na versão 2023.40 ou superior.
3. Crie a connection com segredo, nunca com texto puro. Use CREATE CONNECTION referenciando o escopo de segredos do workspace. Isso exige o privilégio CREATE CONNECTION no metastore.
4. Crie o foreign catalog. Com CREATE CATALOG no metastore e propriedade da connection (ou CREATE FOREIGN CATALOG sobre ela), o banco remoto passa a ser espelhado no Unity Catalog.
5. Conceda privilégios como em qualquer catálogo. BROWSE é concedido por padrão a todos os usuários da conta; Data Reader entrega leitura. A governança é do lado do Unity Catalog, e a conexão com a fonte usa as credenciais da connection — não as do usuário final.
6. Valide o plano antes de liberar. Rode EXPLAIN FORMATTED e leia o que realmente será enviado ao banco remoto.
7. Decida a fronteira e documente. Se a query passou de exploratória a recorrente, promova-a para um pipeline de ingestão. Federação que virou produção sem revisão é dívida técnica silenciosa.

CREATE CONNECTION core_bancario TYPE sqlserver
OPTIONS (
  host '<hostname>',
  port '<port>',
  user secret('<escopo>','<chave-user>'),
  password secret('<escopo>','<chave-password>')
);

CREATE FOREIGN CATALOG IF NOT EXISTS core_bancario_fc
USING CONNECTION core_bancario
OPTIONS (database '<database>');

Onde o pushdown decide o resultado

Este é o ponto que separa quem opera federação de quem apenas a habilitou. O motor tenta empurrar predicados para o banco remoto e reduzir o volume que trafega pela rede. Quando não consegue, o filtro é removido da query remota e aplicado depois, no Databricks — ou seja, o banco devolve tudo.

O exemplo está na própria documentação: WHERE name ILIKE 'john' não tem tradução no MySQL e não é empurrado, então a consulta remota vira um SELECT *. Mas WHERE name ILIKE 'john' AND date > '2025-05-01' empurra a comparação de data e reduz drasticamente o que atravessa a rede. Combinar predicados com AND é uma técnica de custo, não de estilo.

Para o conector de SQL Server, a matriz oficial é razoavelmente generosa — filtros, projeções, LIMIT, Contains/Startswith/Endswith e funções de string, matemáticas e diversas (parciais, só em expressões de filtro) funcionam em qualquer compute; agregações, operadores aritméticos, booleanos e bitwise e ordenação com LIMIT exigem DBR 13.3 LTS ou superior. Funções de janela não são empurradas. Já o join pushdown é GA e ligado por padrão para Redshift, Snowflake e BigQuery, mas está em Public Preview para Oracle, PostgreSQL, MySQL, SQL Server e Teradata, exige DBR 17.2+ e um toggle na página de Previews — e só suporta INNER, LEFT OUTER e RIGHT OUTER. Um join sobre um agregado ou sobre um LIMIT não desce.

Três alavancas de performance que fazem diferença real em produção:

• fetchSize define quantas linhas vêm por viagem. Por padrão a maioria dos conectores JDBC busca os dados atomicamente, o que estoura memória em tabelas grandes. A recomendação oficial é um valor alto, como 100000. Requer DBR 16.1+ ou SQL warehouse 2024.50+. Atenção: isso lê em lotes, não em paralelo.
• Leitura paralela (numPartitions, partitionColumn, lowerBound, upperBound) engaja múltiplos executors e muda a ordem de grandeza em tabelas grandes. Requer DBR 17.1+ ou SQL warehouse 2025.25+. A coluna de partição precisa ser numérica, bem distribuída e indexada — e lowerBound/upperBound só definem o passo, não filtram linhas.
• Views importam onde são criadas. Leitura paralela não funciona sobre uma view criada no Databricks que referencia uma tabela federada. Crie a view no banco de origem.

O outro lado: quando ingerir é a resposta certa

Ingestão deixou de ser sinônimo de escrever pipeline. O Lakeflow Connect entrega conectores gerenciados governados pelo Unity Catalog, rodando em compute serverless sobre Lakeflow pipelines, com leitura e escrita incrementais. Os tipos disponíveis cobrem quase todo o espectro:

• Conectores de banco (CDC) — MySQL, PostgreSQL e SQL Server via change data capture, com ingestion gateway e staging storage para captura contínua.
• Conectores baseados em query — consultam a fonte em um agendamento usando uma coluna de cursor, sem gateway e sem staging. É a alternativa leve quando não existe infraestrutura de CDC.
• Conectores SaaS — Salesforce, HubSpot, Jira, Workday e outros.
• Conectores de arquivo — SharePoint e Google Drive, estruturados e não estruturados.
• Conectores de streaming — barramentos de mensagem e fontes de evento.

A ingestão incremental é o mecanismo: na primeira execução o pipeline traz tudo o que foi selecionado e, nas seguintes, apenas o que mudou — quando a fonte permite. Vale registrar que os conectores gerenciados estão em estados de disponibilidade variados, então confirme o seu antes de desenhar em cima dele.

O conector baseado em query merece destaque porque é exatamente o meio-termo que falta nessa discussão. Ele resolve o caso “eu preciso disso todo dia às 6h, mas não tenho CDC” sem transformar a fonte em dependência de tempo real e sem exigir gateway.

A tabela de decisão

Um padrão maduro raramente escolhe um lado: federe para descobrir, espelhe para entregar consumo, ingira para operar. A migração incremental é o caso canônico — federe o legado para manter o negócio funcionando enquanto os domínios críticos são migrados de verdade.

O caso Azure: SQL Server, Synapse e OneLake

No Azure Databricks, a federação cobre SQL Server, Azure SQL Database e Azure SQL Managed Instance no mesmo conector, além do Azure Synapse (SQL Data Warehouse). A autenticação para SQL Server aceita OAuth via Microsoft Entra ID, OAuth machine-to-machine e usuário/senha — e a conexão é sempre cifrada com SSL.

Sobre rede, há um detalhe que resolve muita discussão com o time de segurança: todo o tráfego de consulta vai diretamente entre o compute do Databricks e o banco externo; nem o Unity Catalog nem o control plane ficam no caminho do dado. A exceção é OAuth — a troca de token parte do control plane, que precisa alcançar o endpoint de autenticação.

E existe uma peça nova e especificamente Azure: a catalog federation de OneLake. Ela permite analisar dados de um Fabric Lakehouse ou Warehouse sem copiá-los, com acesso somente leitura, exigindo DBR 18.0+ em modo Standard ou SQL warehouse 2025.40+, autenticação por Managed Identity (via Access Connector) ou service principal, e três tenant settings habilitados no Fabric pelo administrador. Para quem vive o dilema “Databricks ou Fabric”, essa é a resposta arquitetural: não duplicar.

Databricks e Microsoft Fabric: como trabalhar nos dois

O dilema “Databricks ou Fabric” quase nunca é uma decisão real. Na prática as duas plataformas já estão na mesma empresa: o time de engenharia vive no Databricks, e finanças, controladoria e as áreas de negócio vivem no Power BI. A pergunta útil não é qual sobrevive — é em que direção o dado atravessa, e quem manda na permissão depois que ele atravessa.

Existem duas direções, e elas são simétricas:

Databricks lendo o Fabric. É a catalog federation de OneLake da seção anterior: você registra o OneLake como catálogo externo e lê Lakehouse e Warehouse do Fabric sem cópia, somente leitura, com o Unity Catalog governando quem pode consultar.

Fabric lendo o Databricks. Aqui o objeto é o Mirrored Azure Databricks catalog, um item do Fabric que espelha um catálogo do Unity Catalog. E o nome engana: a documentação classifica isso como metadata mirroring, não como replicação. Nas palavras da própria página: “there is no data movement or data replication. Only the Azure Databricks catalog structure is mirrored to Fabric and the underlying catalog data is accessed through shortcuts”. O dado permanece no seu ADLS Gen2; o Fabric cria shortcuts que apontam para ele.

Espelhar um catálogo cria dois itens no Fabric: o item de Azure Databricks e um SQL analytics endpoint somente leitura, consultável em T-SQL. A partir daí o Power BI consome em Direct Lake, sem import e sem cópia adicional.

O papel do OneLake — onde o dado do Fabric realmente mora

Nenhuma das duas direções faz sentido sem entender o que está embaixo do Fabric. Todo item do Fabric — Lakehouse, Warehouse, catálogo espelhado — endereça o OneLake, descrito pela documentação como “a unified data lake for your whole organization”, incluído automaticamente em cada tenant. Há um OneLake por tenant: não se cria um segundo, não se apaga o que existe e não há infraestrutura para provisionar. Ele é construído sobre o Azure Data Lake Storage e guarda tabelas em Delta Parquet ou Iceberg — dois formatos abertos, nenhum proprietário.

Três consequências práticas para a decisão deste artigo.

Uma cópia, vários motores. “All Fabric analytics engines work with data directly in OneLake” — Spark, T-SQL, KQL e Power BI leem o mesmo arquivo. Pago o custo de materializar uma vez, trocar de motor não cobra de novo. É o oposto do padrão antigo de um data mart por ferramenta.

O shortcut é o mecanismo, não um detalhe de implementação. Um shortcut é uma referência a dados que vivem em outro lugar — outro workspace, ADLS Gen2, S3, Dataverse, on-premises — e o OneLake os apresenta como se fossem locais. É por isso que espelhar o catálogo do Databricks não move byte: o espelhamento cria a estrutura, e é o OneLake que alcança o seu ADLS Gen2 por shortcut. Quando a origem muda, a mudança aparece do outro lado sem pipeline no meio.

A autorização do lado do Fabric é do OneLake, não do Unity Catalog. Os papéis de segurança do OneLake são deny-by-default: ninguém enxerga nada até ser explicitamente incluído em um papel, com escopo de tabela, pasta ou schema. E a lista de itens suportados diz muito sobre a natureza do espelhamento — para o Azure Databricks mirrored catalog a única permissão possível é Read. Não existe escrita ali, nem por engano.

Há uma armadilha nesse modelo que merece negrito: papel de workspace ganha de papel do OneLake. A documentação avisa que Admin, Member e Contributor recebem Write no OneLake automaticamente e, com isso, sobrepõem qualquer papel de leitura restrita que você tenha configurado. Restringir uma coluna no OneLake e deixar o analista como Contributor do workspace é o mesmo que não restringir nada.

A fronteira de governança — o ponto que derruba projeto

Este é o parágrafo que justifica o artigo inteiro, e a documentação é literal:

“Unity Catalog policies and permission aren’t mirrored in Fabric. Users can’t reuse Unity Catalog policies and permissions in Fabric. Permissions set on catalogs, schemas, and tables inside Azure Databricks doesn’t carry over to Fabric workspaces. You need to use Fabric’s permission model to set access control on objects in Fabric.”

Ou seja: o formato atravessa a fronteira, a permissão não. Delta é a ponte — os dois lados leem Delta sem conversão, e o OneLake ainda faz virtualização de metadados nos dois sentidos, expondo tabelas Delta para leitores Iceberg e tabelas Iceberg como Delta para as cargas do Fabric. Mas o modelo de acesso reinicia do zero quando o dado aparece no Fabric, e a credencial usada na conexão do espelhamento é a que executa todas as consultas de dado. Se você montou uma governança fina no Unity Catalog e assume que ela chega no Power BI, você tem um vazamento de acesso esperando para ser descoberto em auditoria.

O mesmo raciocínio vale para o atalho mais baixo nível: um shortcut de ADLS Gen2 apontando direto para a pasta de uma tabela Delta. Não copia dado, o schema sincroniza sozinho — e o Unity Catalog não governa nada nesse caminho. Quem manda é o RBAC do storage mais a segurança do workspace do Fabric.

O que não atravessa

O espelhamento filtra silenciosamente parte do catálogo. Não são espelhados:

• tabelas com políticas de RLS/CLM (row-level security e máscara de coluna);
• tabelas federadas de Lakehouse Federation — federação não se aninha;
• tabelas de Delta Sharing;
• streaming tables;
• views e materialized views;
• tabelas externas que não estejam em formato Delta.

Some-se a isso que a sincronização automática cobre adição e remoção de schemas e tabelas — a documentação não inclui mudança de coluna nessa lista — e que a propagação de alterações no dado leva “anywhere from a few seconds to several minutes”. Nada disso impede a arquitetura; tudo isso quebra a promessa se você prometeu tempo real.

Como trabalhar no Fabric na prática

1. Decida a direção antes da ferramenta. Consumo executivo e self-service em Power BI puxam para o espelhamento. Enriquecer engenharia com um dado que já vive no Fabric puxa para catalog federation de OneLake. As duas direções coexistem sem conflito.
2. Prepare o Unity Catalog para exposição. O workspace precisa de Unity Catalog habilitado, e o acesso externo ao catálogo precisa estar liberado — sem isso o catálogo simplesmente não aparece na hora de espelhar.
3. Deixe o storage alcançável. A conta de ADLS Gen2 usada pelo workspace do Databricks precisa ser acessível ao Fabric. Com firewall ligado, use trusted workspace access — e saiba que, nesse caminho, políticas de RLS/CLM e ABAC do Unity Catalog não são aplicadas na camada de storage.
4. Recrie a autorização no Fabric, explicitamente. Trate como projeto, não como detalhe: mapeie grupos do Entra ID, defina papéis de workspace e papéis de segurança do OneLake — lembrando que o papel de workspace prevalece sobre a restrição de leitura. Existe um caminho documentado de aproximar os dois modelos, mas ele é manual e paralelo, nunca automático.
5. Verifique o runtime e a região. O Fabric Runtime precisa ser no mínimo Spark 3.4 com Delta 2.4, e o espelhamento de catálogo do Databricks é oferecido em uma lista específica de regiões — Brazil South está entre elas.
6. Escolha o mecanismo pelo objeto, não pelo hábito. Catálogo inteiro governado pelo Unity Catalog → espelhamento. Uma pasta Delta avulsa fora do Unity Catalog → shortcut de ADLS Gen2. Tabelas Iceberg → shortcut de Iceberg, com a virtualização do OneLake resolvendo o formato.

Vale registrar onde a orientação oficial existe e onde ela falta. Os guias de decisão de fundamentals do Fabric — o de armazenamento e o de pipeline, dataflow ou Spark — não citam espelhamento. Mas o Data Factory publica uma comparação direta entre Copy job, Mirroring, Copy activity e Eventstreams, e o OneLake publica a página que coloca shortcut e espelhamento lado a lado. O que continua sem página é a comparação entre espelhamento e catalog federation do Databricks no mesmo quadro: essa fronteira, a do critério acima, é autoral e precisa ser revisada a cada release.

Espelhamento no Fabric: uma palavra, três mecanismos

Até aqui “espelhar” apareceu com um sentido só — o catálogo do Unity Catalog exposto no Fabric sem mover byte. Só que o Fabric usa a mesma palavra para três mecanismos diferentes, e confundi-los é a origem de metade das discussões improdutivas sobre custo e latência.

• Database mirroring — replicação de verdade. “When you create a mirrored database, its data is stored in Delta Lake format within OneLake.” O dado é copiado, em Delta, dentro do OneLake. É o caminho de Azure SQL Database, SQL Managed Instance, SQL Server, Oracle, Cosmos DB, PostgreSQL, MySQL (preview), BigQuery, SAP e SharePoint List (preview).
• Metadata mirroring — o que o artigo já descreveu: “Metadata mirroring doesn’t replicate data. Instead, it relies on OneLake shortcuts to reference source data in place.” É o caso do Azure Databricks e do catálogo Dremio (preview).
• Open mirroring — a porta aberta: “Open mirroring enables any application to write change data directly into a mirrored database in Fabric.” Sem conector nativo, a sua aplicação escreve o change data direto numa landing zone.

A régua contra o shortcut também está documentada: “Shortcuts add selected data to the OneLake namespace. Mirroring adds an external database or catalog and determines whether its data can be accessed in place or must be replicated.” Traduzindo para a decisão: shortcut é recorte, espelhamento é catálogo — e quem decide se copia é o mecanismo, não você. Há até um caso sem escolha: “If your source stores data in a proprietary format, mirroring is your only option.”

E há uma armadilha honesta: as próprias páginas oficiais discordam sobre o Snowflake. A tabela do mirroring/overview o classifica como database mirroring; a de onelake/unify-data o agrupa com Databricks e Dremio em metadata mirroring. A página do produto explica o porquê: tabelas gerenciadas e views são replicadas e convertidas para Parquet, enquanto tabelas Iceberg são alcançadas por shortcut. É híbrido. Se a sua decisão depende de haver ou não cópia, confirme por tipo de objeto, nunca por nome de fonte.

A conta do espelhamento — o que é grátis e o que não é

Este é o argumento que mais aparece em reunião, e ele é verdadeiro pela metade. O que é gratuito está escrito: “Background Fabric compute used to replicate your data into Fabric OneLake is free and doesn’t consume capacity.” E o armazenamento vem com franquia: “Mirroring offers a free terabyte of mirroring storage for every capacity unit (CU) you purchase” — uma F64 dá 64 TB dedicados a espelhamento.

O que não é gratuito, na mesma página: “The compute for querying data by using SQL, Power BI, or Spark is charged at regular rates.” Replicar não cobra; ler cobra. Some-se a isso três detalhes que decidem projeto: capacidade pausada para de espelhar (“a paused or deleted capacity affects mirroring and no data is replicated”), a fatura da origem continua existindo — no Snowflake o espelhamento roda continuamente, sem janela nem agendamento, e cada reseed consome compute de lá — e a versão do gateway muda a conta: com on-premises data gateway anterior a junho de 2026, as transações de OneLake do espelhamento de Oracle e SQL passam a consumir CUs. “Grátis” é do lado do Fabric, exatamente a mesma lição bilateral da query federation.

Quatro decisões que aparecem em campo

1. Core em Azure SQL Database, relatório regulatório diário no Power BI → espelhe. A heurística oficial por camada do medalhão é explícita: “Gold data (reporting and analytics on processed data) – Use Mirroring. If you already have ETL processing elsewhere and mainly need to bring curated data into Fabric for reporting, Mirroring is the simplest and most cost-effective choice.” Antes de prometer data: o servidor lógico precisa de Managed Identity como identidade primária, o principal precisa de ALTER ANY EXTERNAL MIRROR, e o banco não pode ter CDC ligado, nem Synapse Link, nem estar espelhado em outro workspace. O teto é de 1.000 tabelas — e com “espelhar tudo” ele pega as mil primeiras em ordem alfabética e descarta o resto sem avisar.

2. Eventos de aplicação em Cosmos DB, analytics sem tocar no transacional → espelhe. O argumento é forte: “Your Azure Cosmos DB data is continuously replicated directly into Fabric OneLake in near real-time, without any performance impact on your transactional workloads or consuming Request Units (RUs).” Dois pontos surpreendem quem vem do mundo Synapse: não é o Synapse Link — “Mirroring does not use Azure Cosmos DB’s analytical store or change feed as a change data capture source” —, o pré-requisito é backup contínuo (o de 7 dias é gratuito), e o escopo é API for NoSQL apenas. MongoDB, Cassandra, Gremlin e Table ficam de fora.

3. Fonte sem conector nativo → open mirroring. Sua aplicação, ou um parceiro do ecossistema, escreve Parquet ou texto delimitado numa landing zone por tabela, com um _metadata.json obrigatório declarando keyColumns e uma coluna final __rowMarker__ marcando insert, update, delete ou upsert. Decida o keyColumns com calma: depois de definido não muda — e sem ele não existe update nem delete.

4. Ingestão bruta, camada bronze → não espelhe. A mesma página oficial manda o contrário: “Bronze data (raw ingestion) – Start with Copy job.” Espelhamento não transforma, não agenda e não deixa você escolher o comportamento de escrita.

O que o espelhamento não faz

A tabela oficial de comparação é generosa ao listar o que o espelhamento não suporta: sem agendamento customizado, sem gestão de tabela e coluna, sem copy behavior, sem incremento por watermark, sem ELT dirigido por metadados — e, num item que merece leitura atenta, sem performance previsível. O guia de integração fecha o retrato: transformação nenhuma, código nenhum, destino “Mirrored database (stored as read-only Delta table in Fabric OneLake)”.

• É somente leitura, e sem cálculo derivado. “Mirrored databases are read-only. You can’t create calculated columns or calculated tables directly on a mirrored database.” Precisa derivar coluna? Lakehouse com shortcut por cima.
• DDL custa caro. “When there’s DDL change, a complete data snapshot is restarted for the changed table, and data is reseeded.” Um dbt que mexe no DDL em agenda vira reseed em loop.
• A segurança da origem não atravessa. Em Azure SQL, “permissions are currently not propagated to the replicated data in Fabric OneLake”: máscara dinâmica, permissão de objeto e rótulo de confidencialidade ficam para trás. No Snowflake, RLS e CLS também não são replicados.

Repare que essa última é exatamente a fronteira do mirrored catalog do Databricks, agora em outra fonte. Não é peculiaridade do Unity Catalog: é padrão do espelhamento. O formato atravessa; a permissão, não.

Falta o miúdo que derruba conciliação: colunas json e vector bloqueiam a tabela inteira, LOB acima de 1 MB é truncado em silêncio, datetime2(7) perde o sétimo dígito e datetimeoffset(7) perde o fuso. E o espelhamento roda VACUUM com retenção padrão de um dia — time travel longo não é promessa que se faça aqui.

Depois de espelhar: o caminho de volta para o Databricks

O dado espelhado vira Delta no OneLake, então a intuição diz que o Databricks o lê por catalog federation. Só que a lista oficial de itens suportados é curta: “The following Fabric data items are supported: Fabric Lakehouse, Fabric Warehouse.” Mirrored database não está nela.

O que dá para montar, juntando duas páginas: um shortcut do Lakehouse para as tabelas espelhadas e a federação apontando para o Lakehouse — lembrando que “shortcuts to mirrored tables are read-only”. Esse encadeamento é dedução minha, não receita oficial; trate como hipótese a validar no seu tenant. O caminho alternativo, esse documentado, é o Databricks lendo o OneLake pelo endpoint ABFS com service principal.

Boas práticas para produção

• Trate cada foreign catalog como um contrato com um dono nomeado, com data de revisão. Federação sem prazo de validade vira arquitetura por acidente.
• Nunca aponte um dashboard de alta concorrência para uma tabela federada de OLTP. Se ele existe, é candidato à ingestão.
• Sempre use EXPLAIN FORMATTED antes de promover uma consulta federada, e confira o bloco PushedFilters/PushedJoins.
• Escreva predicados pensando em pushdown, combinando com AND para que a parte empurrável reduza o tráfego mesmo quando o resto não desce.
• Ajuste fetchSize e leitura paralela conscientemente — e valide os requisitos de runtime antes, porque a sintaxe aceita e simplesmente não otimiza em versões antigas.
• Guarde credenciais em secret scopes, nunca em texto puro no CREATE CONNECTION.
• Monitore os dois lados. Custo de federação é bilateral: o seu compute e o compute da fonte. Um painel que só mostra DBUs está contando metade da história.
• Prefira catalog federation quando ela existir para a sua fonte — a consulta roda só no seu compute e é mais econômica.
• Se o dado vai para o Fabric, planeje a autorização como entrega separada. Permissão do Unity Catalog não acompanha o espelhamento, e descobrir isso em auditoria custa caro.
• Antes de espelhar, cheque os bloqueios da origem. Em Azure SQL, CDC ligado, Synapse Link, durabilidade de transação retardada ou espelhamento ativo em outro workspace impedem o recurso — descobrir isso na véspera do go-live é caro.
• Trate o teto de 1.000 tabelas como decisão de escopo, não como limite técnico: com “espelhar tudo”, o que passar do teto é descartado em silêncio, em ordem alfabética.
• Não prometa time travel sobre dado espelhado. O espelhamento roda VACUUM com retenção padrão de um dia.
• Separe o que é grátis do que é cobrado. A replicação para o OneLake não consome capacidade; a leitura em SQL, Power BI ou Spark consome, e a origem continua faturando o próprio compute.

O que precisa estar de pé

Fundação — inventário e autoridade sobre o acesso. Cada connection e cada foreign catalog tem dono, propósito declarado e classificação de dado. As credenciais estão em segredos, os privilégios são concedidos por grupo e o time sabe dizer quais consultas atravessam a fronteira do lakehouse.

Está de pé quando você consegue listar todo acesso federado e explicar, para cada um, por que ele ainda não foi ingerido.

Produção com contexto — a carga na modalidade certa. Exploração e prova de conceito vivem em federação; carga recorrente e crítica vive em ingestão incremental. Planos de query são inspecionados, pushdown é verificado e o impacto sobre a fonte é medido, não presumido.

Está de pé quando a promoção de uma consulta federada para pipeline é uma decisão registrada, e não a reação a um incidente na origem.

Escala e eficiência — a fronteira como portfólio. Federação e ingestão são revisadas juntas, com custo dos dois lados, latência observada e criticidade de negócio. Migração incremental usa federação como ponte com data de término, e catalog federation substitui query federation onde a fonte permite.

Está de pé quando mover uma carga de federada para ingerida (ou o contrário) não quebra governança, linhagem nem consumidor.

A ordem é causal, não cronológica. Não existe fronteira eficiente sem inventário, nem promoção segura sem leitura de plano.

Referências oficiais

• Conectar-se a bancos e catálogos externos (Azure Databricks)
• O que é query federation?
• Recomendações de performance para Lakehouse Federation
• Executar consultas federadas no Microsoft SQL Server
• Recomendações de rede para Lakehouse Federation
• Habilitar catalog federation do OneLake
• Conectores gerenciados no Lakeflow Connect
• Catálogo espelhado do Azure Databricks no Microsoft Fabric
• Segurança do espelhamento do Azure Databricks no Fabric
• Limitações do espelhamento do Azure Databricks no Fabric
• Atalhos do OneLake
• Tabelas Iceberg no OneLake
• OneLake, o data lake unificado
• Modelo de controle de acesso do OneLake
• Espelhamento no Microsoft Fabric — visão geral
• Unificar dados com shortcuts e espelhamento do OneLake
• Comparando Copy job, Mirroring, Copy activity e Eventstreams
• Open mirroring no Fabric
• Formato da landing zone do open mirroring
• Limitações do espelhamento de Azure SQL Database
• Limitações do espelhamento de Snowflake
• Espelhamento do Azure Cosmos DB
• Consumo de armazenamento do OneLake

Perguntas frequentes (FAQ)

Posso escrever em uma tabela federada?

Não. Lakehouse Federation é somente leitura, tanto em query federation quanto em catalog federation. Quando você precisa de escrita — ou de uma fonte não suportada, ou de mais controle sobre execução e paralelismo — o caminho documentado é a Spark Data Source API.

Federação sempre reduz custo porque não copia dados?

Não. Ela elimina armazenamento duplicado e trabalho de pipeline, mas em query federation parte da execução acontece no compute do banco externo, e esse custo raramente aparece no painel de quem tomou a decisão. Consulta recorrente e de alto volume tende a ficar mais cara federada do que ingerida.

Qual a diferença prática entre query federation e catalog federation?

Query federation empurra a consulta por JDBC e executa nos dois lados. Catalog federation lê direto do object storage e roda apenas no compute do Databricks, o que a documentação descreve como mais econômica e mais otimizada em performance. Quando as duas existirem para a sua fonte, prefira catalog federation.

O Unity Catalog aplica a segurança que já existe no banco de origem?

Não automaticamente. A governança granular é aplicada pelo Unity Catalog sobre a foreign table, e a conexão com o sistema externo usa as credenciais definidas na connection — não as do usuário final. Regras que vivem apenas na origem precisam ser reproduzidas ou repensadas no catálogo.

E se eu preciso de recorrência, mas não tenho CDC na origem?

Esse é exatamente o espaço dos conectores baseados em query do Lakeflow Connect: eles consultam a fonte em um agendamento usando uma coluna de cursor, sem exigir gateway nem staging storage.

Espelhar o catálogo do Databricks no Fabric copia meus dados?

Não. A documentação classifica o recurso como metadata mirroring: só a estrutura do catálogo é espelhada, e o dado continua sendo lido no seu ADLS Gen2 por meio de shortcuts. O que muda de lugar é o ponto de consumo — não o arquivo.

As permissões do Unity Catalog valem dentro do Fabric?

Não. Políticas e permissões do Unity Catalog não são espelhadas, e o controle de acesso precisa ser recriado no modelo do Fabric. Além disso, as consultas de dado usam a credencial da conexão do espelhamento, não a identidade de quem consulta no Fabric.

Preciso escolher entre Databricks e Fabric?

Não, e o artigo defende o contrário: catalog federation de OneLake resolve a direção Fabric → Databricks, e o mirrored catalog resolve Databricks → Fabric. Nenhuma das duas copia o dado. A decisão real é onde vive a autoridade sobre a permissão.

Quem controla o acesso do lado do OneLake?

Os papéis de segurança do OneLake, em modelo deny-by-default, com escopo de tabela, pasta ou schema — e, no catálogo espelhado do Azure Databricks, só com permissão de Read. O detalhe que costuma passar batido é a precedência: quem tem papel de Admin, Member ou Contributor no workspace recebe Write automaticamente e sobrepõe a restrição de leitura que você configurou.

Espelhamento no Fabric copia o dado ou não?

Depende do mecanismo, e é por isso que a pergunta confunde. Database mirroring replica de verdade, em Delta, dentro do OneLake — Azure SQL, Cosmos DB, Oracle, PostgreSQL, SQL Server. Metadata mirroring não copia nada e resolve por shortcut — Azure Databricks e Dremio. Open mirroring é a sua aplicação escrevendo o change data numa landing zone. O Snowflake é híbrido: tabelas gerenciadas e views replicam, tabelas Iceberg vão por shortcut.

O espelhamento do Fabric é realmente grátis?

A replicação é: o compute de background não consome capacidade, e há um terabyte de armazenamento de espelhamento gratuito por unidade de capacidade comprada. Ler cobra — consulta em SQL, Power BI ou Spark é faturada normalmente. Além disso a capacidade precisa estar rodando (pausou, parou de replicar) e a origem continua faturando o próprio compute.

Posso espelhar a camada bronze e economizar pipeline?

Não é o que a orientação oficial recomenda: o guia de decisão do Data Factory manda usar Copy job para dado bruto e reserva o espelhamento para a camada gold, quando o processamento já aconteceu em outro lugar.

O Databricks consegue ler um mirrored database do Fabric?

Não pelo caminho direto: a catalog federation de OneLake suporta Fabric Lakehouse e Fabric Warehouse, e mirrored database não aparece na lista. O contorno plausível é um shortcut de Lakehouse para as tabelas espelhadas, federando o Lakehouse — dedução a partir de duas páginas, não receita documentada. Documentado mesmo é ler o OneLake pelo endpoint ABFS com service principal.

Conclusão

A pergunta “federar ou ingerir?” quase nunca tem resposta única em uma organização real — ela tem resposta por carga. Federação é a ferramenta certa para encurtar o ciclo de descoberta, sustentar uma migração incremental e evitar cópia onde a cópia não agrega. Ingestão é a ferramenta certa para tudo que precisa rodar amanhã de novo, com latência previsível e sem transformar um sistema transacional em dependência analítica.

O antipadrão não é usar federação. É deixar de decidir — permitir que um atalho de exploração vire, por inércia, a arquitetura de acesso a dados da empresa. Vale para a fronteira com o Fabric também: espelhar um catálogo é barato e reversível, e o OneLake resolve muito bem o lado do armazenamento — uma cópia, vários motores, shortcut no lugar de pipeline. O que o OneLake não resolve é quem pode ler o quê: essa conta reinicia do zero do outro lado. Se ninguém assume a autorização ali, o que você exportou não foi só o dado — foi o risco. A fronteira entre os modelos precisa de dono, de critério e de revisão. É isso que separa um lakehouse governado de um conjunto de ponteiros com sorte.

👉 Se você está avaliando Lakehouse Federation para acelerar entrega — especialmente com dados regulados, sistemas legados e times de dados sob pressão de prazo —, este é o ponto de decisão. Quer trocar ideia sobre arquitetura de dados no Databricks e Unity Catalog? Me chama no LinkedIn.