TLDR
Databricks Lakehouse Federation is Databricks’ query federation platform. It lets you query external systems like Snowflake, Redshift, BigQuery, SQL Server, Oracle, and Teradata directly through Unity Catalog, without moving the data first. Two modes exist: query federation, which pushes SQL down to the source over JDBC, and catalog federation, which reads Iceberg or Delta tables straight from object storage using only Databricks compute. As of 2026 it also reaches Salesforce Data 360, Microsoft OneLake, and Snowflake’s managed Iceberg tables. Setup requires Unity Catalog , Databricks Runtime 13.3 LTS or later, and a Pro or Serverless SQL warehouse. Access stays read-only.
A retail analytics team needs one dashboard that blends Snowflake sales data, an on-prem SQL Server inventory feed, and a BigQuery marketing export. The old answer meant weeks of ETL pipeline work before anyone saw a number. Databricks Lakehouse Federation exists to remove that wait.
It lets Databricks query data sitting inside Snowflake, Redshift, BigQuery, SQL Server, and a growing list of other systems directly through Unity Catalog, without copying a single row. The feature has expanded fast since its 2023 debut. By 2026 it reaches from Oracle to Microsoft’s OneLake.
In this article, we’ll cover how Lakehouse Federation works, the setup SQL and performance tuning, which sources it supports today, its real limits, and how to decide when to federate versus migrate.
Key Takeaways Databricks Lakehouse Federation lets you query Snowflake, Redshift, BigQuery, SQL Server, Oracle, and Teradata directly from Databricks without copying data first. Two federation types exist: query federation (JDBC pushdown, compute runs in both places) and catalog federation (direct object storage access, Databricks compute only, more cost effective). 2026 additions confirmed in Databricks’ own documentation include Google BigQuery, Salesforce Data 360, Snowflake catalog federation for managed Iceberg tables, and Microsoft OneLake catalog federation. Setup requires Unity Catalog, Databricks Runtime 13.3 LTS or later, and a Pro or Serverless SQL warehouse; join pushdown for Oracle, PostgreSQL, MySQL, SQL Server, and Teradata needs Databricks Runtime 17.2 or later. Federation fits ad hoc reporting and phased migrations best. High-volume, latency-sensitive workloads still perform better once the data lives natively inside Databricks.
What Is Databricks Lakehouse Federation? Databricks Lakehouse Federation is the query federation platform built into Databricks. It gives governed, read-only access to external data through Unity Catalog foreign catalogs, with automatic query pushdown and table-level access controls, as Databricks’ own documentation describes it. No ingestion pipeline runs first, and none of the usual medallion architecture staging happens either.
The query goes out, the answer comes back, and the source data never leaves its original system.
Two distinct mechanisms sit under that one name, and mixing them up is the most common source of confusion.
1. Query Federation Query federation pushes a Databricks query down to an external relational database over JDBC, then runs the remaining logic on Databricks compute. It works against operational databases and data warehouses such as MySQL, PostgreSQL, SQL Server, and Snowflake. Databricks recommends it for ad hoc reporting, proof-of-concept work, and situations where the data must stay live in its source system, according to Databricks’ comparison of the two approaches .
2. Catalog Federation Catalog federation skips the source database’s compute entirely. Unity Catalog reads the underlying Iceberg , Delta, or Hive tables straight from object storage using only Databricks compute, which Databricks documents as more cost-effective and better performing than query federation. It fits platforms with open table formats and a compatible catalog service, such as AWS Glue , an external Hive metastore, Salesforce Data 360, Snowflake, and, on Azure, Microsoft OneLake.
3. Why Unity Catalog Sits at the Center Every foreign system shows up in Unity Catalog as a foreign catalog, mirroring the source’s schemas and tables. Analysts query it with ordinary SQL, and Unity Catalog applies the same access grants, lineage tracking, and audit logging it uses for native Databricks tables. That single governance layer , not the query mechanics, is what actually makes federation usable at enterprise scale.
Planning a Federated or Migrated Data Architecture? Kanerika’s Databricks, Snowflake, and Fabric teams can walk through which sources to federate, which to migrate, and how to govern both under one catalog.
Schedule a Meeting →
How Databricks Lakehouse Federation Works Every foreign system shows up in Unity Catalog as a foreign catalog. A connection stores the host and credentials for that system, a foreign catalog mirrors its schemas and tables, and from there analysts query it with ordinary SQL, joins included.
Where the query runs is the one difference worth internalizing. For query federation, Databricks pushes predicates and, where supported, joins down to the source engine over JDBC, then finishes execution on Databricks compute .
For catalog federation, the whole query runs on Databricks compute against the object storage location directly. That difference is why catalog federation costs less per query when the source supports it. The full setup, with the actual SQL for each step, comes next.
Setting Up Databricks Lakehouse Federation The setup runs in the same order for every source. The specifics change per connector, but the shape stays constant: create a connection, mirror it as a foreign catalog, grant access, then query. The examples below use PostgreSQL and Snowflake because they cover both the simple and the awkward cases.
1. Check Permissions and Runtime First Creating a connection needs the CREATE CONNECTION privilege on the metastore, and creating the foreign catalog needs CREATE CATALOG plus ownership of (or CREATE FOREIGN CATALOG on) that connection. In workspaces auto-enabled for Unity Catalog, admins hold both by default, per the Databricks Snowflake federation guide . Compute must run Databricks Runtime 13.3 LTS or later in Standard or Dedicated access mode, and SQL warehouses must be Pro or Serverless on 2023.40 or later.
2. Create the Connection A connection stores the host, port, and credentials for one external system. The DDL is short, and the credential should come from a secret rather than a literal string.
CREATE CONNECTION postgres_connection TYPE POSTGRESQL
OPTIONS (
host 'postgres-demo.lb123.us-west-2.rds.amazonaws.com',
port '5432',
user secret('secrets.r.us', 'postgresUser'),
password secret('secrets.r.us', 'postgresPassword')
);
Databricks explicitly recommends the secret() function over plaintext credentials in the OPTIONS clause, so the value lives in the secret service instead of the statement text, according to the Databricks CREATE CONNECTION reference . The TYPE accepts DATABRICKS, MYSQL, POSTGRESQL, REDSHIFT, SNOWFLAKE, SQLDW, SQLSERVER, and a few others.
3. Create the Foreign Catalog The foreign catalog mirrors a specific database inside that connection. Once created, it populates with every schema and table the authenticating user can see.
CREATE FOREIGN CATALOG postgres_catalog USING CONNECTION postgres_connection
OPTIONS (database 'my_postgres_database');
From here, a query looks exactly like a query against a native table: SELECT * FROM postgres_catalog.public.orders WHERE order_date > '2026-01-01'. Analysts do not need to know the data lives in PostgreSQL.
4. Grant Access Through Unity Catalog Because the foreign catalog is an ordinary Unity Catalog object, grants work the same way. That is the whole point of routing federation through the catalog rather than through raw JDBC connection strings.
GRANT USE CATALOG ON CATALOG postgres_catalog TO `analytics_team`;
GRANT SELECT ON CATALOG postgres_catalog TO `analytics_team`;
5. Watch the Snowflake OAuth Token Expiry Snowflake adds one wrinkle worth flagging before it bites. Its built-in OAuth integration sets OAUTH_REFRESH_TOKEN_VALIDITY to 90 days by default, and once the refresh token expires the connection stops working until someone re-authenticates, per the Databricks Snowflake OAuth setup .
Set that duration deliberately and put a calendar reminder on the rotation. This is the single most common reason a federated Snowflake connection that worked for months suddenly fails.
How to Tune Databricks Lakehouse Federation Query Performance Federation performance is mostly about how much data crosses the network. The less that moves, the faster the query. Four levers do most of the work, and all four are documented in Databricks’ performance recommendations .
1. Push Filters Down With the AND Operator Databricks tries to push predicates to the source so it fetches fewer rows. Some expressions cannot be translated to the source dialect, though. An ILIKE filter against MySQL, for example, cannot push down, so Databricks pulls every row and filters locally.
The fix is to pair the non-pushable filter with a pushable one using AND. A WHERE name ILIKE 'john' AND date > '2025-05-01' sends the date filter to the source, cutting the row count before the ILIKE runs in Databricks. The date comparison does the heavy lifting; the local filter cleans up what is left.
2. Set fetchSize to Avoid Out-of-Memory Errors Most JDBC connectors fetch a result set atomically by default, which can blow past available memory on a large table. Setting fetchSize makes the connector read in batches instead.
SELECT * FROM postgres_catalog.public.orders WITH ('fetchSize' 100000);
Databricks recommends a large value such as 100,000, since too-small batches drag out total query time. This needs Databricks Runtime 16.1 or later, or a Pro or Serverless SQL warehouse on 2024.50.
3. Enable Parallel Reads for Large Tables For big tables, parallel reads split the query across executors instead of streaming through one connection. It needs a numeric, evenly distributed, ideally indexed partition column.
SELECT * FROM postgres_catalog.public.orders WITH (
'numPartitions' 4,
'partitionColumn' 'id',
'lowerBound' 1,
'upperBound' 1000000
);
The lowerBound and upperBound values only decide the partition stride, not which rows return. Every row still comes back. Parallel reads need Databricks Runtime 17.1 or later on Pro or Serverless warehouses using 2025.25.
One gotcha worth knowing: parallel reads do not work against a Databricks-created view over a federated table. Create the view in the source database instead.
4. Verify Pushdown With EXPLAIN FORMATTED Do not assume a filter or join pushed down. Running EXPLAIN FORMATTED on the query shows exactly which operations Databricks sent to the source, with PushedFilters and PushedJoins entries in the physical plan. If an expensive join is missing from the pushed section, that is where the latency is coming from.
5. Cache Frequent Queries With Materialized Views When the same federated query runs repeatedly, hitting the source every time risks throttling it and running up egress charges. A materialized view stores the result as a physical table in Databricks and refreshes it on a schedule, so most reads never touch the source at all.
Materialized view refreshes run on serverless Lakeflow pipeline compute, billed separately from the querying warehouse, per Databricks’ materialized view documentation . Cost scales with the data processed on each refresh, not the warehouse size, so a nightly refresh of a heavy federated join is often far cheaper than letting every analyst rerun it live.
Supported Data Sources in Databricks Lakehouse Federation for 2026 The connector list has grown well past its original scope, and several 2026 additions matter for teams that checked this list even a year ago and stopped.
1. Query Federation Sources Source Category Join Pushdown MySQL Operational database Public Preview PostgreSQL Operational database Public Preview Microsoft SQL Server Operational database Public Preview Oracle Operational database Public Preview Teradata Data warehouse Public Preview Amazon Redshift Data warehouse GA by default Snowflake Data warehouse GA by default Google BigQuery Data warehouse GA by default Azure Synapse (SQL Data Warehouse) Data warehouse Not listed Salesforce Data 360 CRM / CDP Not listed Another Databricks workspace Lakehouse Not listed
Teams retiring a legacy warehouse instead of federating it indefinitely, an Oracle to Snowflake migration being one common example, follow a different path entirely from the one covered here.
2. Catalog Federation Sources Catalog federation reaches a shorter but fast-growing list. It covers the legacy internal Databricks Hive metastore, an external Hive metastore, AWS Glue metastore, Salesforce Data 360, Snowflake, and, on Azure Databricks, Microsoft OneLake, according to Databricks’ catalog federation overview .
Snowflake catalog federation only covers Snowflake Managed Iceberg tables. Non-Iceberg Snowflake tables still route through query federation, as Databricks’ Snowflake catalog federation guide confirms.
3. What Changed at Data and AI Summit 2026 Two additions stand out from Databricks’ June 2026 summit. Salesforce’s connector, originally released as the Salesforce Data Cloud connector in September 2024 , now carries the Salesforce Data 360 name across current documentation. OneLake Catalog Federation also reached General Availability, letting Azure Databricks query Microsoft Fabric’s OneLake storage through Unity Catalog with no data copy required, as Kanerika’s own DAIS 2026 recap covers in more detail.
That same summit paired the connector updates with a broader push into agentic AI, including Genie and the expanded Agent Bricks platform. Both lean on the same governed foreign catalogs described here.
Databricks Consulting and Implementation As a registered Databricks Consulting Partner, Kanerika designs the Unity Catalog governance, foreign catalogs, and migration path so federation holds up in production, not just in a pilot
Explore Databricks Services →
Lakehouse Federation Limits Worth Knowing Federation removes a migration project, but it does not remove physics. Several limits show up in nearly every deployment, and knowing them ahead of time saves a debugging session later.
1. Read-Only Access Federated queries cannot write back to the source system. Databricks’ own comparison table lists write support as not supported for both query and catalog federation. Any update still has to happen inside the source system directly, then becomes visible through federation on the next read.
2. What Actually Pushes Down Not every operation reaches the source. For Snowflake, Databricks pushes down filters, projections, limits, joins, most aggregates, common string and date functions, window functions like rank and row_number, and sorting, per the Databricks Snowflake pushdown list .
Anything outside that set runs in Databricks after the data lands, which is exactly why the AND predicate trick and EXPLAIN FORMATTED matter. Assume nothing pushes down until the plan confirms it.
3. Join Pushdown Coverage and Rules Join pushdown is generally available by default for Redshift, Snowflake, and BigQuery. For Oracle, PostgreSQL, MySQL, SQL Server, and Teradata it stays in Public Preview, needs Databricks Runtime 17.2 or later plus a Pro or Serverless warehouse on 2025.30, and must be toggled on in the Previews page, per Databricks’ performance recommendations .
Only inner, left-outer, and right-outer joins qualify. A join also fails to push down if a limit, offset, or aggregate sits below it in either branch, though those same operations push fine when they sit on top of the join.
4. Naming and Case Traps Unity Catalog lowercases table and schema names, which quietly breaks lookups if the source uses mixed case. A case-sensitive Snowflake database identifier has to be wrapped in double quotes in the foreign catalog definition to preserve its casing, per the Databricks Snowflake guide .
Two source tables whose names collapse to the same lowercase string means only one gets imported, and a name that is invalid in Unity Catalog is skipped entirely. These are silent failures rather than errors, so they are easy to miss until a table appears to be missing.
5. Memory and Result-Set Size Each foreign table reference triggers a subquery on the remote system that returns data in a single stream by default. A large result set can exhaust worker memory before the query finishes. The fetchSize batching and parallel-read partitioning covered earlier exist precisely to prevent this, so any query pulling a big table should set them rather than hoping the default holds.
6. Network, Egress, and Concurrency Costs Every federated query travels directly between Databricks compute and the source system, and Databricks’ best practices guide flags an egress charge whenever the source sits in a different cloud or region. The source’s own concurrency limits apply too, so a busy operational database can throttle federated queries the same way it throttles any other client. High-frequency federated access to a production database is a good way to slow that database down for everyone else, which is the strongest argument for caching heavy queries in a materialized view.
Federate or Migrate: A Decision Framework The real question is rarely whether federation works, because it usually does. The question is whether federating a given source is cheaper over its lifetime than moving it once, and how it compares to the zero-copy options other platforms offer. A few factors settle most cases.
1. How Other Platforms Solve the Same Problem Databricks is not the only platform selling zero-copy access to someone else’s data, and it helps to know where Databricks alternatives and Databricks competitors differ. Microsoft Fabric uses shortcuts to reference OneLake or external storage without copying, and the newer OneLake Catalog Federation path now lets Azure Databricks read that same OneLake data through Unity Catalog directly.
Snowflake’s external tables and its Horizon and Open Catalog features solve it from the other direction, letting Snowflake query data outside its managed storage. Databricks’ Snowflake catalog federation mirrors that logic in reverse, reading Snowflake’s Managed Iceberg tables directly from object storage. When a team already runs more than one of these, the mechanics matter less than picking one governed surface.
2. Query Frequency and Volume Federation shines for low-frequency, exploratory access. A source queried a few times a week for a report costs almost nothing to federate and would be wasteful to migrate.
A source hit thousands of times a day by dashboards is the opposite. Each of those queries pays network transfer, source compute, and Databricks compute, and the running total quickly passes what a one-time migration would have cost.
3. Source System Load Tolerance A federated query runs against the live source. If that source is a production operational database already near its concurrency ceiling, federation adds load exactly where the system can least afford it. A read-replica or a migrated copy removes that risk.
When the source cannot take the extra traffic, the decision is made regardless of query volume.
4. Latency Requirements Federated queries carry unavoidable overhead: network round trips, JDBC serialization, and any local processing for operations that could not push down. For a report that can wait a few seconds, that is fine, but a sub-second dashboard or a real-time agent workflow will nearly always run faster on native Databricks tables or a materialized view. Choosing where each workload should live is the same call covered in Kanerika’s Databricks vs Snowflake vs Fabric decision framework .
5. Migration Cost and Risk Migration is not free either. It carries project cost, cutover risk, and the effort of rebuilding logic on the new platform. Federation loses ground once query volume gets heavy and consistent, and at that point a proper data modernization project that migrates the source and retires the connection is usually the more durable answer.
6. The Phased Pattern in Practice The strongest teams do not treat this as a binary. They federate a source to expose it under Unity Catalog immediately, watch which tables get queried hard, cache the heavy repeat queries in materialized views, and migrate only the tables the evidence justifies.
Consumers query the same catalog throughout, so a table moving from federated to native is invisible to them. That is federation and migration working together rather than competing, and it is the pattern Kanerika builds most engagements around.
Common Use Cases for Databricks Lakehouse Federation 1. Ad Hoc Reporting Without a Migration Project Analysts get one-off access to an operational database for a specific report, without opening a ticket for a full ingestion pipeline. The report ships straight out of whichever data analytics tools the team already uses, and nothing new gets left behind to maintain.
2. Phased Unity Catalog Migration Teams standardizing on Unity Catalog rarely move everything on day one. Catalog federation lets some tables stay in their original system while others migrate, all visible under the same governance layer during the transition. That matters for teams also running Mosaic AI workloads that expect one consistent source of truth.
3. Cross-Platform Governance Under One Catalog Enterprises running Databricks alongside Snowflake, Fabric, or Salesforce increasingly want one place to see who can access what, regardless of where the data physically sits. Unity Catalog’s foreign catalogs give that single view without forcing a platform consolidation first. That kind of view also feeds naturally into a broader AI maturity assessment of where an organization’s data estate actually stands.
Databricks Lakehouse Federation: How Kanerika Helps Kanerika is a Microsoft Solutions Partner for Data and AI with Analytics Specialization and Microsoft Fabric Featured Partner, and a registered Databricks Consulting Partner . The team also holds Snowflake Select Tier Partner status. That matters directly here since Snowflake sits on both sides of federation: as a query source today, and as a catalog federation target for Managed Iceberg tables.
Kanerika’s data governance team maps foreign catalog permissions to existing access policies before a single connection goes live, so federation does not turn into a new, ungoverned door into source systems. That work draws on the same Microsoft Purview and Unity Catalog expertise behind Kanerika’s AI governance practice and the KANGovern, KANComply, and KANGuard suite.
For sources a client plans to retire rather than federate indefinitely, Kanerika’s FLIP migration accelerator automates the move to Databricks, Microsoft Fabric, or Snowflake. Confirmed deployments show 50 to 60% less migration effort and 75% lower annual licensing costs. The Informatica to Databricks path is the most common one Kanerika runs for clients standardizing on the Lakehouse.
Kanerika runs live delivery practices across Databricks , Snowflake , and Microsoft Fabric , which matters because most federation decisions involve at least two of the three. That comparative experience is why Kanerika’s guidance on Databricks vs Snowflake and Databricks vs Snowflake vs Fabric comes from implementation work rather than a vendor comparison sheet. The same governed-catalog thinking carries into Kanerika’s agentic AI deployments, including a real-time compliance AI agent and a context-aware AI agent that both depend on trustworthy, governed data underneath them.
Deciding What to Federate and What to Migrate? Kanerika’s Databricks, Snowflake, and Fabric teams can walk through which sources to federate, which to move, and how to govern both under one catalog.
Schedule a Meeting →
Case Study: Faster Document Processing with Databricks Workflows The client is a fast-growing AI-powered sales intelligence platform that provides go-to-market teams with real-time, contextual insights on companies and industries. With a data engine fueled by large-scale web scraping and document ingestion, their existing infrastructure struggled to keep up with the growing volume of unstructured data . Their stack included MongoDB, Postgres, and legacy JavaScript-based processing, requiring a major overhaul to scale effectively and deliver timely insights.
Client’s Challenges Outdated document workflows created maintenance bottlenecks, which led to service delivery delays and reduced operational agility Disconnected data sources limited visibility across systems, delaying access to timely and reliable insights Unstructured PDF and metadata processes increased manual effort, reducing team productivity and extending turnaround times.
Our Solutions Refactored document workflows from JavaScript to Python in Databricks, improving maintainability and processing speed Integrated disconnected data sources into Databricks, improving visibility and enabling faster, more reliable insights Simplified PDF, metadata, and classification workflows in Databricks, reducing manual effort and accelerating insight delivery
Results 80% Faster Document Processing 95% Improved Metadata Accuracy 45% Accelerated Time-to-Insight
Wrapping Up Databricks Lakehouse Federation solves a specific problem well: seeing data that lives somewhere else without a migration project standing between the question and the answer. Query federation and catalog federation cover different scenarios, and the 2026 connector list, now including BigQuery, Salesforce Data 360, Snowflake catalog federation, and OneLake, reaches further than most teams expect. Treat federation as a phase rather than a permanent architecture. Once query volume gets heavy and consistent, migrating the source usually costs less than federating it forever, and that is the judgment call worth making early rather than after the bill arrives.
FAQs
What Is Databricks Lakehouse Federation? Databricks Lakehouse Federation is Databricks’ query federation platform. It lets Databricks query external systems such as Snowflake, Redshift, BigQuery, and SQL Server directly through Unity Catalog, without first copying the data into Databricks. Governance, access controls, and lineage all apply to the federated tables the same way they apply to native ones.
Is Databricks Lakehouse Federation Free to Use? There is no separate license fee for the feature itself, but every federated query still consumes Databricks compute, and query federation can also add load and cost on the source system. Materialized views and caching reduce repeated costs for frequently run queries.
What Data Sources Does Lakehouse Federation Support in 2026? Query federation covers MySQL, PostgreSQL, SQL Server, Oracle, Teradata, Amazon Redshift, Snowflake, Google BigQuery, Azure Synapse, Salesforce Data 360, and other Databricks workspaces. Catalog federation covers Hive metastores, AWS Glue, Salesforce Data 360, Snowflake Managed Iceberg tables, and, on Azure, Microsoft OneLake.
Can You Write Data Back Through Lakehouse Federation? No. Both query federation and catalog federation are read-only. Any insert, update, or delete has to happen directly in the source system, and the change becomes visible through federation on the next query.
What Is the Difference Between Query Federation and Catalog Federation? Query federation pushes SQL down to the source system over JDBC and runs part of the query there. Catalog federation reads Iceberg, Delta, or Hive tables directly from object storage using only Databricks compute, which generally costs less and performs better where it is supported.
What Do You Need to Set Up Lakehouse Federation? A Unity Catalog-enabled workspace, Databricks Runtime 13.3 LTS or later (or a Pro or Serverless SQL warehouse on version 2023.40 or later), and Standard or Dedicated access mode. Newer features such as join pushdown for Oracle, PostgreSQL, MySQL, SQL Server, and Teradata require Databricks Runtime 17.2 or later.
Does Lakehouse Federation Replace ETL or Data Migration? Not for every workload. Federation is well suited to ad hoc reporting and phased migrations, where the source stays live while teams build confidence in the new platform. High-volume, latency-sensitive workloads generally still perform better once the data is migrated natively into Databricks.
Does Lakehouse Federation Slow Down Query Performance? It depends on the source and the query. Predicate and join pushdown reduce network traffic substantially, and join pushdown now runs by default for Redshift, Snowflake, and BigQuery. Filters that cannot be translated to the source system’s SQL dialect still run inside Databricks after the data arrives, which adds latency for those specific queries.
