It is Monday morning at a Fortune 500 enterprise. An analyst opens Excel. The question on her desk: revenue by segment for last quarter, reconciled against a customer-cohort definition that sits in a different system from the revenue ledger. The revenue data is in Databricks. The customer dimension is in Snowflake. The marketing-attribution overlay her finance partner wants her to include is in Microsoft Fabric. She has access to all three. Her firm has invested in all three, over several years.

What she does not have is a single place to ask the question.

She can pivot between three browser tabs, three query editors, three SQL dialects, and three governance models. She can ask one of the three platform-native AI assistants and get an answer scoped to that platform’s catalog. She can wait for her data engineering team to centralize the data in one of the three. These are her options; and none of them are satisfying.

The question this piece is about is not which cloud platform she should prefer. It is what kind of tool serves the person doing the actual work.

The position every cloud vendor is working toward

---

The major cloud data platforms have spent the last two years converging on a shared answer: federation.

Databricks Unity Catalog supports catalog federation to a range of external sources including Snowflake, AWS Glue, and Hive metastores. As of the April 29 announcement, Unity Catalog and Google BigQuery now federate in both directions: Unity Catalog can read Iceberg tables written from BigQuery and other engines, and BigQuery can read Unity Catalog tables – the latter in preview from Google Cloud. Snowflake reciprocates the Iceberg path. The pattern is clear and the engineering investments are real. A vendor’s customer can register a foreign catalog in their primary platform, see the foreign tables in their primary governance UI, and query across the boundary without moving the underlying data.

This addresses a persistent problem for which customers have asked for solutions, namely that data tied to a single platform’s catalog requires either ETL or duplication to be useful elsewhere. Federation removes that requirement for an increasing share of cases. It lets governance, lineage, and access control concentrate in one place rather than fragmenting across platforms. The picture, however, is more complicated.

What federation delivers, and what it does not

---

The limits, documented by the vendors themselves, shape what a federated architecture actually does for the analyst in Excel.

First, the path Databricks describes as more efficient is the catalog-federation path, in which the home platform reads foreign tables directly from object storage using its own compute. That path requires the foreign tables to be in an open format the home platform can read, typically Iceberg. When the foreign data is in a proprietary format – e.g. Snowflake tables not yet migrated to Iceberg – federation falls back to query federation, which pushes the query to the foreign platform and runs it on that platform’s compute. The economics shift accordingly. An enterprise that has not yet completed an Iceberg migration on every platform it uses pays the foreign-compute bill for any data still held in proprietary formats.

Second, federation is hub-and-spoke. One platform is the catalog of record; the others are foreign. The firm has to choose a hub, and the choice has consequences for which platform’s governance model becomes the corporate standard, which platform’s identity provider becomes the enforcement point, and which platform’s bill grows with cross-platform query volume.

Third – and most importantly – the vendors frame federation as a transitional state, not as the production end-state. Databricks positions catalog federation as a way to bridge an in-progress migration to Unity Catalog, or as a hybrid arrangement for firms that need to keep some data in an external catalog. Their recommended end-state is to migrate frequently-queried datasets into the home platform’s managed format. Federation is the bridge while the migration happens.

This tells you what, in their view, federation is designed to do. It is not designed to make an enterprise indifferent to which cloud holds which data. It is designed to make migration to a single home platform less disruptive while it is in progress.

The fourth point follows from the previous three. Most enterprise data is not in Iceberg or comparable open formats today. Migration to open formats is a multi-year program at any enterprise. Until that migration is well-progressed at every platform a firm uses, federation operates in its less-attractive query-federation mode for a meaningful share of the firm’s data – meaning the foreign platform’s compute runs and is billed.

None of this makes federation a bad answer to its own problem. It makes federation a partial answer to the analyst’s problem.

The AI layer makes the federation question moot for the analyst

---

Set the federation limits aside and assume an enterprise has invested the years of work to land a fully bidirectional, fully Iceberg, fully governed cross-platform federation. Assume the catalogs are unified and the foreign tables behave like local ones for read purposes. The analyst in Excel still does not get a unified experience.

The natural-language and AI assistants the cloud vendors sell are not federated. Genie runs in Databricks, against Databricks compute, against Databricks’ catalog and Databricks’ model policies. Cortex Analyst runs in Snowflake, against Snowflake compute, against Snowflake’s catalog and Snowflake’s model policies. Copilot for Fabric runs in Microsoft, against Microsoft compute, against Microsoft’s catalog and Microsoft’s model policies. Each is tightly bound to the platform it ships with, by the same commercial logic that makes any platform vendor reluctant to make its premium AI features the front door to a competitor’s data.

For the analyst, even in the imagined future where federation is complete, she gets three AI experiences, not one. She must learn three prompting conventions, accept three different model-policy regimes, and trust three different sets of guardrails. The unification federation promised at the data layer fragments again at the layer where she interacts.

And the analyst whose firm forbids cloud-AI APIs altogether – the regulated bank, the audit firm, the pharma client with patient data – does not get any of them. That is a subject for a future piece.

What the analyst working today actually needs

---

Step back from the platform debate and look at the requirements as the analyst would state them.

A single interface in Excel that works the same way regardless of which platform holds the data.

Governance enforced at the source, not relocated to a connector or an aggregation layer that the firm’s security team has not vetted. Access controls, row-level filters, and column-level masking applied by the platform that owns the data, exactly as that platform’s owners configured them.

A query path that does not require the firm to first complete a cross-platform federation migration before the analyst can do her job today.

An AI option, when the firm allows one, that works under the firm’s actual constraints – including the constraints of firms that cannot send schemas, queries, or results to a public AI API.

These are requirements, not features. They describe what a tool would have to satisfy to be useful to an analyst working in Excel in 2026. They are agnostic to which vendor builds the tool. The question is which kind of vendor structurally can.

The structural argument for a neutral layer

---

A neutral layer above the clouds – a tool that an analyst uses identically whether her data is in Databricks, Snowflake, or Fabric, that defers to each source platform for governance, and that does not relocate data to a vendor-controlled intermediary – is structurally available to an independent vendor. It is not available to any of the cloud platforms themselves.

The reason is commercial. A cloud platform’s incentive when it builds an Excel connector is to make its own platform the easiest data source to reach from Excel. Building an Excel connector that treats a competitor’s platform as a peer, with the same access path and the same fidelity, conflicts with the same business. This is a description of where each vendor’s product investment will rationally concentrate.

The same argument applies at the AI layer. A cloud platform building a natural-language assistant has every reason to make that assistant excellent on its own data and to make adoption of that assistant a path toward consolidating more workloads on its platform. It has no reason to build an assistant that runs locally on the analyst’s machine, with no telemetry to the platform, and that bypasses its own AI services. An independent vendor has the opposite incentive structure.

This is the position Exponam Analyst Intelligence occupies. One add-in inside Excel. Same interface across Databricks, Snowflake and Microsoft Fabric. Each source platform’s governance enforced at the source. A SQL-endpoint path for full query support and a Delta Sharing path where appropriate. Private and bring-your-own LLM options for natural-language query, available to firms whose policies preclude public AI APIs. No data routed through Exponam infrastructure.

The cloud platforms are doing the right thing for their own platforms. The claim here is about which kind of vendor can occupy the neutral position the analyst actually needs, and which kind structurally cannot.

Closing

---

Federation will continue to mature. Cross-cloud governance will improve. Iceberg adoption will broaden, and the cost-effective path through catalog federation will cover more of an enterprise’s data than it does today. None of that changes the structural argument.

The analyst working in Excel, on the data mix she has today, in the regulatory environment she operates in today, needs a layer above the clouds – not a deeper integration of any one cloud’s tooling into the others.

That layer is what we built.