Everywhere you look, companies are talking about Databricks or Fabric. Three years ago it was all Snowflake. So is Snowflake losing? Short answer from a working thread of engineers, consultants, and people inside the buildings: no — but the question itself is the wrong shape.
Is Snowflake losing the race?
Every practitioner in this thread converged on roughly the same answer, from different angles.
Snowflake isn't losing — the race itself was never a single race. Databricks is growing faster and winning more greenfield deals in specific situations (ML-heavy teams, regulated industries needing BYOC). Snowflake still has the larger, more mature installed base as a governed SQL warehouse. Fabric is gaining share for reasons almost entirely unrelated to product merit. None of that is "overtaking" in the way the hype cycle implies.
What actually changed in three years isn't who's winning — it's who's talked about. Hype rotates on its own schedule, decoupled from revenue, retention, or platform quality. The clearest evidence for this in the thread: Oracle has a $350B market cap and Snowflake has roughly $95B, and nobody is out there hyping Oracle. Oracle is not losing. It just exited the "exciting growth story" phase of its life decades ago. Snowflake and Databricks are still in that phase — which is exactly why they generate this much conversation.
Real reasons, not just hype
Origin advantage
Databricks grew out of Spark and machine learning, where lineage and reproducibility were existential from day one. Unity Catalog is the product of that history — governance was foundational, not bolted on.
Architecture advantage
Classic Databricks architecture keeps the data plane — clusters and the data itself — inside the customer's own cloud account. For regulated industries, "our data never sits in a third party's storage" isn't a preference, it's a disqualifier for anything else.
Paradigm advantage
The lakehouse paradigm — one copy of data, many engines — became the industry's reference architecture. Databricks was the original lakehouse company, which gives it a "we called it" credibility Snowflake has had to retrofit its way into.
One more data point from the thread, offered with a caveat: a dbt representative reportedly estimated dbt usage runs roughly 3x higher on Snowflake than on Databricks. The read on this wasn't "Databricks is worse" — it's a different paradigm. Snowflake users lean on dbt because Snowflake's SQL-warehouse users needed an external tool to get version control and transformation discipline. Databricks users more often build their own pipelines natively, so a dbt-shaped tool is optional rather than load-bearing. A migration story mentioned in the thread — Asana reportedly moving from Snowflake to Databricks — was flagged by the person raising it as an interesting but somewhat self-promotional case study, worth reading skeptically rather than as proof of a trend.
What the thread said each platform is actually good at
Illustrative, not measured — a rough plot of where consensus landed across six axes practitioners kept returning to.
Convergence, not collision
Each platform's current edge traces back to its origin story — and the rivalry has visibly accelerated both roadmaps.
Growing share, not growing on merit
Nobody in the thread — including an actual Fabric user who ran a two-year enterprise pilot — thinks Fabric is competing with Snowflake and Databricks on product quality.
The pattern described: Fabric is genuinely useful for small teams or for extending what a single data analyst can do — a real, if narrow, use case. At enterprise scale, multiple people in the thread reported the opposite experience: a two-year enterprise pilot as a preferred partner concluded it "simply wasn't ready," with inconsistent access control between modules — visible evidence that different Microsoft teams built different parts of Fabric without lining up on fundamentals. One practitioner's summary: "give it a couple of years, the sales team would have sold it to enough people to make it worth using" — i.e., the product may eventually earn its share, but isn't earning it today.
Nobody in the thread has seen a company move from Snowflake to Fabric. Fabric's growth comes almost entirely from companies already locked into Azure licensing, where it shows up as "free" — a framing repeatedly called misleading, since the real cost shows up later as lock-in. It was described bluntly as "a tool that Finance makes you use, or a service provider that's only trained on it — it never wins on merit."
What people actually said
"I think Snowflake have gotten a bit obsessed with beating Databricks, rather than just being a great product by itself."— practitioner, extensive user of both
"Their first all-hands, people asked about Databricks this-and-that, and the new CRO basically said: I don't give a **** about Databricks. I want us focusing on having a great platform."— self-identified current Snowflake employee
"Databricks is a Microsoft partner and native to its ecosystem, so it's an easy step up."— Fabric user, two-year enterprise pilot
"You can literally tell different teams have made different parts of it — none of them line up, especially access control."— practitioner, ran a Fabric preferred-partner pilot
"Snowflake runs its own storage and its own compute — that's not even an option for us from a security standpoint, regardless of compliance certifications."— practitioner in a regulated industry
"There's no buzz about Oracle and its market cap is $350B. Oracle is not losing."— consultant, platform advisor
"The split came down to Iceberg interoperability. Snowflake's Horizon catalog wrote to external Iceberg tables cleanly — Databricks' Unity Catalog couldn't, reliably, at the time."— consultant, hybrid-architecture case study
"Fabric is a tool that Finance makes you use, or you have a service provider that's only trained on it. It never wins on merit."— consultant, weekly platform advisory
Split by workload, not by brand
Snowflake for the warehouse, Databricks for ML pipelines, on the same client. Neither platform "lost" — the decision was made per workload.
Why Snowflake, here
Horizon catalog wrote to external Iceberg tables cleanly. Billing was predictable for this workload's shape — no cluster tuning required to avoid overpaying.
Why Databricks, here
ML pipelines needed the notebook/Spark-native environment. Unity Catalog's Iceberg interop was less reliable at the time, so it stayed out of that specific job.
A related bet raised in the thread: some see Databricks pulling ahead structurally because of Genie and an emerging ontology/semantic layer — the idea that once natural-language BI is good enough, companies will prefer one platform with a unified semantic layer over stitching meaning across multiple tools. That's a bet on convenience and unification beating best-of-breed — notably, the same structural bet Fabric is making through bundling, just backed by stronger underlying engineering, in this framing.
Real product complaints, not just narrative
Two concrete gripes came up that are worth separating from the culture/stock noise, because they're about the product itself.
Dynamic Table failures
Recent DT errors got a "split up the query" response rather than a root-cause explanation. Once you're manually decomposing a Dynamic Table's logic to work around engine limits, you've lost the point of using one over a stored procedure with explicit control flow.
No native modeling tool
No confirmed agreement with any third-party modeling vendor exists — but Snowflake's broader pattern is to stay narrowly focused on the core engine and leave adjacent categories (BI, orchestration, data modeling) to ecosystem partners. Defensible strategy; leaves a real gap as semantic layers become more central.
A voting machine, not a weighing machine
The original question leaned on a single former employee's account: culture gone bad, can't retain good people, stock "keeps crashing." What came back from people closer to it was more specific and more mixed.
- A quarterly review program was described as having become a disguised layoff mechanism, unevenly applied — including against people on leave or of a certain age — a real, specific complaint, not a vague vibe.
- That program is reportedly no longer in use, following internal morale and culture problems it caused.
- A current employee of seven years reports never having had a bad manager, framing "constant change" as a byproduct of scaling from roughly 1,100 to over 9,000 employees.
- A new head of sales reportedly told an all-hands to stop obsessing over Databricks and focus on the product — read internally as an active course-correction.
Both things can be true in a company that size: a specific program was a real problem for a period, and the aggregate day-to-day experience is reported as good by longer-tenured staff. One data point doesn't settle it either way.
