The enterprise data cloud debate has been running for six years on the wrong axis. Every keynote cycle produces a new benchmark, a new SKU, a new named-competitor callout. But the platform layer is converging faster than the feature differentiation can keep up. As of April 22, 2026, Google Cloud, Databricks, and Snowflake all ship — or are actively shipping — Apache Iceberg as a default table format, an open catalog API, a native MCP server, a governed semantic layer, a named natural-language analytics agent, and access-aware retrieval enforced at the catalog level. The common floor is visible across all three. Presence is not parity — depth, enforcement, and production-readiness still vary — but the architectural direction is no longer reversibly contested. What sits on top of that converging floor — the agentic runtime — is the actual moat question. And none of the three has yet won that layer.
The Wrong Debate
The dominant reading of Google’s announcement treated the Lightning Engine claim as the headline. Up to 2× the price-performance of “the proprietary market alternative” is a sharp line. It refers, without naming, to Databricks Photon — the vectorized Spark engine that has been one of Databricks’ most durable technical moats for half a decade. A hyperscaler calling out a named competitor that directly is rare. Analyst response treated it as the thesis.
It is not. It is the tell.
There are other plausible readings, and they are not mutually exclusive. The callout could be competitive signaling to analysts. It could be a catch-up narrative against Photon’s brand dominance in Spark workloads. It could be pricing-pressure positioning meant to erode Databricks’ enterprise Spark footprint. All three motives are real. None of them cancels the structural reading — they layer on top of it. The architectural question is not whether Google’s motive is singular. It is whether Google would have picked a named engine-layer fight at all in a world where the substrate underneath was still actively contested. The answer is no. That is the tell, whatever else motivates the claim.
The Lightning Engine claim is a performance claim, bound by the usual caveats: whose benchmark, on what workload, with what data shape, at what scale. None of that is what matters architecturally. What matters is that Google is confident enough in the direction of the substrate underneath to pick a named fight on the engine layer. Named engine fights land differently depending on what is settled underneath. Strip the benchmark noise, and the engine claim reads as a signal that Google believes the substrate direction is no longer in active contest.
Performance bake-off
Lightning Engine vs. Photon. Knowledge Catalog vs. Horizon. Spanner Omni vs. Snowpark Container Services. BigQuery fluid scaling vs. Snowflake warehouse sizing. The debate resolves through benchmarks, demo reels, and third-party validation.
SurfaceSubstrate convergence
All three vendors now ship the same core architectural floor — Iceberg, open catalog, MCP, semantic layer, access-aware retrieval. Depth varies; the commitment does not. Differentiation collapses to the agentic runtime layer on top. Google’s bi-directional federation makes Unity Catalog and Polaris into read-sources for its Knowledge Catalog. The moat is reforming one layer up.
MoatThe 2× claim is not the thesis. It is the confidence signal.
The Substrate Convergence
Strip the marketing from the three vendor positions and the directional commitment is unmistakable. Every major enterprise data platform now ships — or is actively shipping — the same core architecture. The components arrived at different times under different names. By April 2026, the lineup is visible across all three.
Presence is not parity. The nine cells below show the same architectural commitments shipping across Google, Databricks, and Snowflake, but at different depths of maturity. Some are production-grade at scale: Unity Catalog’s multi-year deployment footprint, Snowflake Cortex in GA across the installed base, Databricks’ MLflow lineage. Some are differentiated by pedigree that the others cannot easily replicate: Google Search re-ranking under the Knowledge Catalog, Databricks’ OBO authentication model, Snowflake’s SQL-native developer experience. Some are early preview or uneven in enterprise adoption: Knowledge Catalog itself, bi-directional federation, MCP integration across the board. The grid shows the architectural commitment. Depth and maturity are still in contest.
Add to this: every vendor ships Apache Iceberg as a first-class table format. Every vendor exposes an open catalog API (Unity OSS, Apache Polaris, Iceberg REST via Knowledge Catalog). Every vendor offers zero-ETL convergence between operational and analytical data (AlloyDB↔BigQuery, Lakebase, Snowflake Postgres). The common floor is not marketing. It is architectural.
When the common floor converges this deeply, the vendor who moves first on the layer above it sets the terms for the layer above that. April 22 is the first move that forces the layer transition.
The Lightning Engine Tell
Read the Lightning Engine callout in its actual context. Google’s language: Lightning Engine delivers up to 2× the price-performance over “the proprietary market alternative.” The alternative is unnamed because it does not need to be named. In the Spark ecosystem, the proprietary alternative is Photon. That is the only plausible referent.
Google’s claimed price-performance edge of Lightning Engine for Apache Spark over “the proprietary market alternative.” The unnamed alternative is Databricks Photon — the vectorized Spark engine at the core of Databricks’ performance story. The claim is less interesting than the willingness to make it.
The claim itself is testable, caveat-heavy, and workload-dependent. But the strategic signal it carries is unambiguous. A year ago, Google Cloud did not pick named engine-layer fights with Databricks. The reason was not politeness. The reason was that the substrate underneath was still in contest — Delta Lake vs. Iceberg, Unity vs. Polaris, proprietary catalogs vs. REST. In that world, an engine-layer fight is downstream of a substrate-layer loss. Nobody picks a fight on the visible end of a conflict they haven’t yet won on the invisible end.
The willingness to make the 2× claim publicly, without hedging, tells you what Google believes about the substrate. Google believes the direction is no longer reversible — Iceberg has effectively become the default interoperability layer, Iceberg REST is the lingua franca, MCP is the emerging tool-calling standard — and the terrain of contest has moved up to the engine and the agentic runtime. Read that way, the callout is a status update. Not bravado.
Named engine fights land differently depending on what is settled underneath. Google picks this one because the substrate direction is no longer in active contest. The 2× claim is noise. The willingness to make it is the signal.
Bi-Directional Federation Is the Actual Move
The announcement’s strategic center of gravity sits elsewhere — in a component that drew less analyst attention because it sounds like plumbing. Bi-directional federation (Preview) lets Google engines read directly from Databricks Unity Catalog on Amazon S3, Snowflake Polaris, and AWS Glue Data Catalog on S3, via Apache Iceberg REST. The same mechanism lets those catalogs read from Google’s Knowledge Catalog. Everything is a peer. Nothing needs to be migrated.
Read this structurally. Databricks spent four years positioning Unity Catalog as the one governance layer that travels with the data. Snowflake donated Polaris to the Apache Foundation specifically to make governance portable across engines. Both moves were designed to neutralize lock-in arguments from rivals. Google’s response is to fully honor that openness — and then quietly become the agent layer that orchestrates across it.
Bi-Directional Federation
A substrate-level capability that reads and writes across catalogs as peers, typically via Apache Iceberg REST. Unity Catalog, Polaris, Glue Catalog, and Google’s Knowledge Catalog become interchangeable read-sources. Data does not move; governance posture does not migrate; the engine on top decides what to do with the federated view.
The strategic implication runs three layers deep.
- First. Federation dissolves migration as a control mechanism. For a decade, the cost of moving data between platforms has been the incumbent’s deepest moat — the reason customers stay. Federation makes that cost irrelevant for read workloads.
- Second. Catalogs stop being destinations and become interoperable control planes. Unity, Polaris, and Knowledge Catalog become peers in a query-routing layer that any of the three can sit on top of.
- Third. The control question migrates upward — to whichever vendor owns the orchestration layer that decides, for any given agent request, where the query routes, which policies apply, and how the multi-step reasoning composes across the federated view.
That vendor does not need to displace the competing catalogs. It needs to out-orchestrate them. Openness ceases to be a posture of humility. It becomes a posture of attack — available only to the vendor best positioned to agent-orchestrate across all three.
What this reframes is the enterprise negotiation itself. A CIO evaluating a platform in 2024 asked: whose data gravity best matches our workload? The answer often kept them on their incumbent, because the cost of moving the data exceeded the gain. The same CIO in 2026 asks a different question: whose orchestration layer reads our existing catalog best — and what does it cost to let that orchestrator become the decision plane across our federated estate? The answer decouples runtime commitment from data gravity. That is the structural break.
This is the move the 2× Photon callout is downstream of. Without the federation capability, the Lightning Engine claim is a standalone performance assertion — interesting, contestable, easily narrated around. With the federation capability, the Lightning Engine claim changes in character. It becomes: your Spark engine is slower than mine, and by the way, my engine can already read your Unity Catalog tables on S3, so the migration conversation is over before it began.
The Counter-Moves Were Already in the Field
None of this is happening in a vacuum. Both incumbents have been building for the agentic runtime layer since late 2025, and the public evidence is not subtle. A week before Google’s announcement, Databricks shipped Unity AI Gateway — a governance layer that extends Unity Catalog to cover how agents access LLMs, MCP servers, and external APIs, with on-behalf-of authentication and unified observability. Agent Bricks Supervisor went GA in February 2026.
Snowflake’s counter is more public still. At Snowflake Build London in early February, the company announced Cortex Code, Semantic View Autopilot, the native integration of Snowflake Postgres into the AI Data Cloud, and a $200 million partnership with OpenAI that makes OpenAI models natively available inside Cortex AI. Snowflake has also been pushing Policy Exchange and Governance Federation APIs through Apache Polaris — the explicit goal being to make fine-grained access controls portable across engines.
Snowflake’s 2026 partnership with OpenAI, unveiled February 2 alongside Cortex Code. Models run natively inside Cortex AI rather than through external integration. Snowflake’s posture: ensure no migration-inducing model gap exists at the intelligence layer while the substrate battle resolves underneath.
Both incumbents have understood the substrate convergence for at least twelve months. Both have been building upward toward the agentic runtime layer. Neither has conceded. What Google’s April 22 announcement does is force the substrate question to closure — by treating the other two catalogs as read-sources — and advance the argument by one layer, where the actual competition is now concentrated.
The New Moat Is the Agentic Runtime
In the healthcare analysis from earlier this week, the argument was that Epic’s moat is not its models but its control of the compliance substrate that makes clinical action permissible. The structural pattern generalizes. In regulated verticals, the moat is compliance. In the enterprise data cloud, the substrate is now a commodity — Iceberg, Polaris, Unity OSS, MCP, all interoperable by design — and the moat is moving to whatever sits on top.
What sits on top is the agentic runtime: the orchestration layer that carries institutional permission to initiate, route, and execute multi-step actions across a federated data estate — and, increasingly, the layer that persists decision traces, enforces policy independent of agent execution, and captures human-in-the-loop judgment where autonomous action is not yet acceptable. Calling it an orchestration layer understates what it actually is. Post 2 in this series makes the full argument that the agentic runtime is better understood as decision infrastructure. For this post’s structural claim, three pieces are enough: governance posture, model access, and federation reach. Every third-party agent running inside Agent Bricks inherits Databricks’ governance posture. Every agent running through Cortex Agents inherits Snowflake’s. Every agent running through Gemini Enterprise inherits Google’s — and, via bi-directional federation, can reason across data that lives in either of the others. The runtime is the new compliance substrate. The runtime is the new moat.
Openness ceases to be a posture of humility. It becomes a posture of attack — available only to the vendor best positioned to agent-orchestrate across all three.
The three-way race has a specific shape — and each shape carries a specific constraint alongside its advantage.
Google’s advantage is federation reach plus the Search re-ranking pedigree plus Gemini integration at every layer of the stack. Its constraint is the enterprise trust gap: a fragmented product surface relative to Databricks’ and Snowflake’s more consolidated enterprise footprints, a weaker installed base among regulated customers, and a reputation — fair or not — for shipping capabilities faster than it hardens them for production at scale.
Databricks’ advantage is control-plane depth — Unity Catalog plus AI Gateway plus the deepest ML and MLOps workflow maturity in the industry, now extended to cover agent-to-tool governance with on-behalf-of authentication and unified observability. Its constraint is reach: less federation surface area than Google today, a smaller BI-user footprint than Snowflake, and a distribution disadvantage in the enterprise segments where procurement already runs through AWS or Microsoft.
Snowflake’s advantage is enterprise distribution, SQL ergonomics, BI-user mindshare, and the OpenAI model access that Google cannot replicate without a counter-partnership. Its constraint is governance depth: Horizon Catalog and Polaris governance federation are credible, but neither matches the audit-grade lineage Unity AI Gateway is built for — a real gap in regulated-industry procurement.
None of these advantages is at the substrate layer. All three are at the runtime.
The Architectural Question
For enterprises evaluating any of the three, the substrate convergence changes the shape of the decision. Data format is no longer a lock-in dimension. Catalog is no longer a lock-in dimension. The questions that matter have moved.
-
1Runtime permission Whose agentic runtime do our agents inherit governance from? Every agent operating inside Agent Bricks, Cortex Agents, or Gemini Enterprise inherits that vendor’s compliance posture. Choosing a runtime is choosing a governance lineage for every downstream action.
-
2Orchestration reach Which runtime can orchestrate across the catalogs we actually use? Federation capability is no longer symmetric. Google’s Knowledge Catalog reads Unity and Polaris as peers. Whether Databricks and Snowflake match that reach in the next two quarters is the single most consequential product question of 2026.
-
3Model portability Does our runtime lock us to a model family, or travel across them? Snowflake’s OpenAI partnership and Databricks’ Unity AI Gateway address this from different angles. Google’s Gemini-first posture is the strongest model lock-in of the three — and also the most coherent integration.
-
4Governance travel Do our access controls travel with agents, or stop at the runtime boundary? Databricks Unity AI Gateway and Snowflake’s Polaris governance federation are designed for this; Google’s native IAM + VPC Service Controls model extends the existing perimeter. None of the three solves the cross-runtime governance question yet.
-
5Substrate neutrality What does our architecture look like if the runtime leader changes? The substrate convergence is the insurance policy. Every enterprise committing to a runtime in 2026 should validate that data estate, catalog, and semantic layer remain portable if the runtime winner is someone else in 2028.
These are not the questions the performance discourse asks. They are the ones that determine whether the agentic data cloud investment survives the next vendor cycle.
A first-pass heuristic for enterprises that need a direction before the full architectural review:
- If the binding constraint is multi-cloud or fragmented-estate data topology, Google’s federation reach is the bet to evaluate first.
- If the binding constraint is audit-grade governance and regulated-workflow compliance, Databricks’ control-plane depth is the bet to evaluate first.
- If the binding constraint is AI-native product velocity and business-user immediacy, Snowflake’s access bet is the bet to evaluate first.
The heuristic does not replace the five questions. It is the order in which to ask them.
The substrate is now common ground. The runtime is the contest. April 22 was the first move that forced the layer transition. It will not be the last.
When the substrate converges, the moat moves up one layer. Agentic runtime is that layer. Google moved first on it — with a bi-directional federation posture that reads the incumbents’ own catalogs as peers, and an engine-layer callout that signals the substrate direction is no longer worth fighting on.
The second post in this series examines the Databricks and Snowflake counter-architectures in full — Unity AI Gateway, Agent Bricks Supervisor, Cortex Code, Semantic View Autopilot, and the OpenAI partnership — and what the three-way agentic runtime race implies for enterprises currently committed to any of them.
