Executive Clarity · 10x Signal: Data & AI Trends

The near-$100 billion gap is a GTM story

Snowflake understood the data problem. Databricks understood the distribution problem. SAP controlled the context. Why investors price the difference at close to $100 billion — and what it teaches about ecosystem go-to-market.

Originally published on LinkedIn in 10x Signal: Data & AI Trends on 21 July 2026 — this is the canonical sapperment edition.

Snowflake understood the data problem. Databricks understood the distribution problem. SAP controlled the context.

One company identified the technical opportunity years early. The other secured the privileged position inside SAP’s future architecture at the exact moment SAP redefined the category.

Investors currently price the difference at close to $100 billion.

In July 2026, Databricks signed a term sheet valuing the company at $188 billion. Snowflake’s public market capitalization stood at roughly $93–95 billion.

Both are exceptional companies. Both have expanded well beyond their original categories into AI, applications, governance and agentic workloads.

Both now have formal SAP partnerships.

So why is one valued at roughly twice the other?

The conventional answer is technology and growth. I think that misses the more important story: Databricks secured the more powerful position inside SAP’s commercial and architectural operating model. Snowflake initially secured access to SAP data.

Why now

February 2025: SAP launched Business Data Cloud with Databricks natively embedded — positioned as a first-party data service, provisioned through SAP for Me.

May 2026: SAP Snowflake and BDC Connect for Snowflake reached general availability. SAP Snowflake became a Solution Extension with unified billing and SAP first-line support; BDC Connect created a zero-copy route for existing Snowflake customers.

July 2026: Databricks was valued at $188 billion on a reported revenue run-rate of approximately $5.4 billion. Snowflake raised its FY2027 product-revenue guidance to $5.84 billion after 34% first-quarter product-revenue growth and 126% net revenue retention.

That puts Databricks at roughly 35x its revenue run-rate and Snowflake at roughly 16x its forward guidance. The comparison isn’t clean — one is a private funding valuation against a run-rate, the other a public market cap against forward guidance — but the signal survives the caveat: the market is not only pricing current revenue. It is pricing position, distribution and future control of enterprise AI workloads.

What the narrative gets right, and what it misses

The usual explanation: Databricks is the AI-native lakehouse, Snowflake arrived late to AI, and the valuations reflect growth rates. There’s truth in it — Databricks is growing faster, and its AI business is scaling quickly. Snowflake is not weak either: Q1 FY2027 product revenue reached $1.33 billion, remaining performance obligations grew to $9.21 billion.

But growth rates don’t explain where the strategic advantage came from. For that, look at SAP.

Snowflake saw the SAP opportunity early — extract or replicate SAP data, reduce fragmented analytics landscapes, later add zero-copy access.

The technical insight was correct: customers didn’t want more brittle ETL and duplicated data.

But SAP had changed the question. When it launched Business Data Cloud in February 2025, the strategic asset wasn’t faster access to SAP tables — it was governed data products, preserved business semantics, process context, lineage, and trusted data for AI.

Databricks was inside that story at launch, positioned as an SAP-managed, natively embedded component of BDC. Snowflake’s equivalent SAP-native packaging didn’t reach general availability until May 2026 — fifteen months later, after the narrative had already been set.

Snowflake treated SAP primarily as a data-access opportunity. Databricks became part of SAP’s operating model. Zero-copy was the right technical idea. It was the wrong lead message.

The failure was not the connector

The original proposition had real value. The failure was the absence — or delayed construction — of a complete commercial system around it.

A product doesn’t become a go-to-market simply because two platforms integrate.

A functioning one has to answer: Who owns the account? Who gets quota credit? Who builds the business case? Who contracts, bills and provisions the service? Who owns adoption after go-live? How does initial use become sustained consumption?

When those answers are unclear, the problem isn’t that sellers don’t understand the product. It’s that the system hasn’t given them a deal they can confidently run.

“Nobody knew how to sell it” is a structural diagnosis

I have seen this pattern repeatedly across SAP accounts and partner organisations — anyone remember UiPath? A technically sophisticated partnership gets announced, the architecture gets presented, the field is told to collaborate — and collaboration is not an operating model. A serious SAP alliance needs several layers working together at once:

Executive alignment. One jointly owned number — pipeline, consumption, target market — with named executives who intervene when priorities conflict, not just an alliance relationship.

Organisational mapping. SAP is not one sales organisation. Industry teams, regional leadership, cloud ERP sellers, BTP specialists and partner managers may all touch the same account. Without a map of who controls the decision, “co-selling with SAP” stays an abstraction.

Seller economics. A seller prioritises what advances the account plan and the number they’re paid on. If an opportunity complicates the SAP motion or produces unclear credit, it loses to deals that are easier to transact — that’s rational behaviour inside the compensation system, not resistance.

Repeatable sales plays built on outcomes, not architecture. “Move SAP data into Snowflake” is not a value proposition. “Improve retail demand forecasting by combining SAP transactions with external data” is. The connector is the enabler; the outcome is the unit of sale.

Commercial packaging. Procurement, provisioning, support and billing are part of the product. Once SAP Snowflake became an SAP Solution Extension with SAP-supported mechanics, it became materially easier for SAP’s own field to sell.

Lighthouse customers. Enterprise sellers believe referenceable customers more than strategy decks. Without a funded lighthouse programme, every new opportunity starts again at zero.

Partner activation. SIs scale the SAP ecosystem. They need packaged services, migration patterns and clear economics — not just product training.

Consumption expansion. Snowflake is a consumption business. Closing the initial contract is the start, not the finish; without tracking activated workloads and expanding usage, a partnership can produce announcements without durable economics.

What an OEM or Solution Extension really means

Legally, OEM agreements and SAP Solution Extensions aren’t identical. Commercially, they reveal the same truth: SAP wants to know who owns every stage of the customer relationship — why the solution belongs in its portfolio, how it’s quoted, contracted, provisioned, supported, and how it reinforces SAP’s own architecture.

The commercial product is not just the software. It’s the complete route from account strategy to sustained customer consumption.

Snowflake eventually built a credible answer through two motions: SAP Snowflake for customers wanting an SAP-managed, net-new experience, and BDC Connect for Snowflake for customers with an established Snowflake estate. That’s a workable strategy. It arrived after Databricks was already part of the BDC launch narrative.

SAP kept the control point — Databricks got next to it

Databricks did not capture the ultimate control point. SAP kept it. SAP owns the applications, business objects, process definitions, authorisations and relationships that make enterprise data meaningful — what a customer is, which entity owns a transaction, what constitutes a valid purchase order, where a process begins and ends. AI agents need that context, not just data.

Databricks’ advantage was becoming part of SAP’s answer at the moment SAP elevated context above compute. That’s a materially different achievement than winning on engine performance.

What the $188 billion is actually pricing

SAP alone doesn’t explain the valuation — that would overstate the case. The premium also reflects growth above 65%, rapidly expanding AI revenue, platform breadth, and investor belief that Databricks can become a central execution layer for enterprise AI.

But the SAP partnership validates that broader thesis. It shows Databricks can get embedded inside another major platform’s strategic architecture rather than remaining an external tool customers integrate themselves. That’s what investors are rewarding: not just adoption, but structural distribution. The valuation is evidence investors believe Databricks has a credible route to control more of the enterprise AI execution layer — not proof that its technology is superior in every category.

Everything above this line is fact or documented company disclosure. What follows — the opportunity sizing, the GTM playbook, and the recovery thesis — is my own inference and judgment, built on that evidence but not sourced to it.

How large was the opportunity, really

Using a working scenario model, not a reported forecast: roughly 30,000 major SAP ECC and S/4HANA customers form the relevant global base, and something like 9,000–12,000 could still be running hybrid ECC/S/4HANA/BTP landscapes by 2028. That hybrid period matters — customers don’t need to finish migrating before investing in data and AI; a fragmented landscape is precisely why they need a governed data layer sooner.

That range doesn’t explain a $95 billion valuation gap on its own — nor should it. The strategic loss was bigger than the revenue: access to the world’s largest enterprises, mission-critical workloads, repeatable references, and a privileged seat in the emerging enterprise-AI architecture. The opportunity wasn’t incremental revenue. It was category ownership.

What a winning GTM could have looked like

Months 0–12 — build the machine: one executive accountable for the joint number; a map of the relevant SAP organisations; 100–150 priority accounts in manufacturing, retail and financial services; three to five outcome-led sales plays; clear quota-credit rules; ten funded lighthouse customers; measurement of activated workloads, not just pipeline.

Months 12–24 — prove repeatability: lighthouse customers turned into published references; expansion to 300–500 named accounts; implementation factories with selected SIs; packaged business cases by industry; quarterly consumption reviews.

Months 24–36 — own the category: the joint architecture becomes the default for selected SAP use cases; expansion from analytics into AI and agentic workloads; a partner portfolio the SAP field can sell without alliance-team hand-holding.

The goal was never more awareness. It was making the motion boringly repeatable — that’s when an alliance becomes a business.

The second act is still open

Snowflake now has two credible routes into the SAP estate, and many large SAP customers already run Snowflake — they won’t rip out a mature platform because SAP embedded a different engine by default. The opportunity is not to replay the connector story more loudly. It’s a disciplined installed-base strategy: find where Snowflake is already strategic, attach SAP business context to existing workloads, activate SAP account teams, mobilise SIs, and turn zero-copy access into measurable consumption.

What this means in practice

If you lead a platform business near SAP: stop asking only whether your technology integrates. Ask who sells it, who gets quota credit, who provisions and supports it, who owns adoption after go-live. Vague answers mean you have a partnership announcement, not an SAP strategy.

If you are an SAP customer: the compute layer is increasingly a choice. The scarcer capability sits above it — governed data products, semantic consistency, process context, and an operating model that makes AI outputs trustworthy. Spend less time debating logos and more time deciding who governs meaning.

If you invest in enterprise technology: don’t ask only which engine is technically superior. Ask which company secured distribution when the ecosystem re-platformed. Technology creates capability; distribution converts it into market power.

If you lead alliances or enterprise sales: “nobody knows how to sell it” should trigger an operating-model review, not another enablement webinar. The problem is rarely seller intelligence — it’s missing incentives, unclear ownership, and too much commercial friction.

The bottom line

Snowflake didn’t miss the first act because zero-copy was a bad idea. It missed because zero-copy solved only one layer of the problem — the larger task was translating good technology into SAP-native packaging, seller incentives, account ownership, support clarity, lighthouse customers and repeatable consumption.

Databricks reached the privileged position first. SAP kept control of the context. And investors placed a near-$100 billion premium on the company they believe is better positioned to turn enterprise data into the execution layer for AI.

In an ecosystem, integration is not the go-to-market. The go-to-market is the product.

A question worth taking away: in your SAP landscape, did you actively choose your data and AI platform — or did the ecosystem’s default choose it for you?

Sources