Choosing a data platform in 2026, by workload not brand

Pull-quote: “All three will run your ordinary workload. The decision is made by the one workload at the edge of your estate.”

Databricks, Snowflake, and Microsoft Fabric will all run the middle of your workload competently, which is why comparing them feature by feature produces a tie and an argument. Three things settle it instead: the one workload at the edge of your estate that only one platform does well, the shape of your usage against three genuinely different billing models, and how much migration you are willing to pay for.

This is written for whoever has to defend the choice, and it does not declare a winner, because a comparison that always ends in the same place is marketing rather than analysis.

What you will be able to do

• State where each of the three platforms is the strongest choice, and say why in one sentence.
• Explain the three billing models accurately: Databricks units, Snowflake credits, and Fabric capacity units.
• Match a usage shape, steady or spiky or scheduled, to the billing model that suits it.
• Enumerate what a migration actually moves, including the parts that are not data.
• Decide when running two platforms with a designed seam beats consolidating onto one.

Why does the platform comparison usually get answered wrong?

Because the question is asked about brands, and every brand now covers the common eighty percent of the work. Ingest files, model tables, run SQL, serve a dashboard, call a model: all three do all five.

The second reason is that most published comparisons answer a career question rather than an architecture one. “Analysts learn Fabric, engineers learn Databricks, warehouse specialists learn Snowflake” sketches where the job adverts are and says nothing about where your invoicing pipeline should run.

The third is that consolidation gets treated as the goal. Tool sprawl is a real cost: separate systems for batch, training, and SQL, three skill sets, three bills, and engineers moving data between them instead of building. Consolidating is often correct, but it is a means. The test is whether one platform carries your edge workload without a compromise you would refuse.

What does each platform genuinely do best?

Each has a centre of gravity visible in its documentation rather than its marketing. Read what the product is designed to make easy and the strengths separate quickly.

Databricks is built around Spark and the lakehouse. Lakeflow Spark Declarative Pipelines handles batch and streaming in SQL and Python, and its streaming tables and materialized views are themselves Unity Catalog managed tables (Lakeflow pipelines). Unity Catalog governs data and AI assets in one namespace, models and agents included (Unity Catalog). If your hard problem is a hundred pipelines, late-arriving data, and models that need retraining and serving, that is the platform shape designed for it.

Snowflake is the strongest of the three at getting data to people outside your walls, and that deserves stating plainly rather than being buried. Secure Data Sharing copies nothing: shared objects are read-only, the data takes no storage in the consumer’s account, and the consumer pays only for the compute they use to query it (Secure Data Sharing). Listings extend that across regions and clouds without manual replication, publicly on the Marketplace or privately to named accounts. Horizon Catalog adds Iceberg read and write from any engine plus catalog-linked databases to AWS Glue and Azure OneLake (Horizon Catalog), and semantic views hold metrics and relationships as schema-level objects for Cortex Analyst to answer against (semantic views).

Fabric wins the last mile in a Microsoft estate. Direct Lake semantic models read Delta tables from OneLake with no import step, in two variants worth knowing apart: Direct Lake on OneLake spans multiple Fabric sources and never falls back to DirectQuery, while Direct Lake on SQL uses the SQL analytics endpoint and does fall back, for instance when the source is a view or enforces row-level security (Direct Lake overview). One capacity covers every workload (What is Microsoft Fabric). For an organisation whose analysts live in Power BI and Excel, that is a real advantage, not a consolation prize.

How do the three billing models change the answer?

More than any feature does, because they price three different usage shapes. This is the section that changes minds in a budget meeting.

Databricks bills consumption in Databricks units. A DBU is “a unit of processing capability per hour, billed on per-second usage”, at a rate set by instance type, workload type, and tier (Azure Databricks pricing). Classic compute produces two bills: DBUs from Databricks plus virtual machines, storage, and egress from your cloud provider. Serverless is one rate that includes the infrastructure (Databricks pricing). This suits bursty, scheduled work: a thirty-minute job costs half of an hour-long one, and idle compute costs nothing.

Snowflake bills credits per running warehouse. Credit consumption doubles with each size step, billing is per second with a one-minute minimum every time a warehouse starts or resumes, and a suspended warehouse consumes nothing (understanding compute cost, warehouses overview). Because that minimum restarts on every resume, an aggressively short auto-suspend can cost more than a longer one when queries arrive in bursts, and Snowflake’s guidance is to match auto-suspend to the gaps in the workload rather than minimising it (warehouse considerations). The default is 600 seconds. This suits interactive SQL with real idle periods.

Fabric bills a fixed capacity, not consumption. Each SKU provides a set number of capacity units per second, doubling by tier, so an F8 provides 8 and an F64 provides 64 (plan your capacity size). Bursting lets an operation exceed that temporarily, and smoothing spreads the accounting over later thirty-second timepoints: interactive operations over five to sixty-four minutes, background operations over twenty-four hours. When sustained demand exceeds the SKU, operations are delayed or rejected, which is throttling (capacity throttling). This suits a predictable daily rhythm with many concurrent users, sized on average rather than peak. It punishes one enormous month-end job on a small SKU, because when the smoothing budget is spent, everyone waits.

Read those three as a question about your own usage, then read where Databricks spend actually goes for the order to fix a consumption bill in.

Which workloads actually settle the decision?

The ones at the edge, where only one platform gives you a clean answer. Everything in the middle is a tie, so stop negotiating it.

• Streaming and change data capture at production scale. Databricks, because declarative pipelines treat streaming tables as governed catalog objects rather than a separate system to operate.
• Model training and serving inside the data’s governance boundary. Databricks, because the model is a securable object in the same catalog as the tables behind it.
• Distributing data to customers, partners, or regulators. Snowflake, because sharing without copies and Marketplace listings solve a problem the other two answer with a pipeline or a file drop.
• Cross-engine access to one physical copy. A tie, and worth saying so: both Snowflake and Databricks expose an Iceberg REST Catalog API. Choose on which catalog should be authoritative, not on the format.
• Containerised or GPU work next to the warehouse. Snowflake, through Snowpark Container Services, which runs an OCI image on a compute pool inside the account (Snowpark Container Services).
• Reporting to several thousand people already in Microsoft 365. Fabric, because Direct Lake and Power BI remove the import step and the licensing conversation at once, and Real-Time Intelligence puts event data beside it for the same audience.

Write your own version before you look at pricing. If it has entries from two platforms, the honest answer is two platforms with a designed seam, which is a legitimate outcome rather than indecision.

What does a migration actually cost you?

Far more than the data movement, which is usually the cheapest part. Six categories carry the cost, and business cases routinely include only the first.

1. SQL dialect and procedural code. Views, functions, and stored procedures do not port. Every MERGE, window function, and date idiom needs testing, and procedural logic often needs redesigning rather than translating.
2. Orchestration. Schedules, dependencies, retries, alerting, and the tribal knowledge about which job must not run before which other. This is where the hidden coupling lives.
3. The semantic layer and every report. Measures, hierarchies, and row-level rules are rebuilt in the target’s own construct, whether a Power BI semantic model, a Snowflake semantic view, or a metric on the lakehouse.
4. The security model. Roles do not map cleanly onto grants, and grants do not map onto workspace roles plus storage-level rules. Rebuild from the entitlement policy, not from the current implementation.
5. Ingestion. Connectors, incremental logic, and watermarks. Each source is a small project and the long tail of small ones stretches the timeline.
6. Parity. Somebody must prove the same report returns the same number afterwards, for named reports over a named period. Without it you have a new platform and an argument.

What makes migration slow is not volume of data, it is volume of undocumented decisions. That is why a platform choice cannot fix an ungoverned estate: if nobody can say today which of three customer tables is authoritative, moving all three somewhere newer preserves that exactly. Settle definitions, ownership, and lineage first, and the pattern that fits your constraints is in data architecture patterns and how to choose one.

When is running two platforms the right answer?

When two of your edge workloads live on different platforms and the seam between them can be a designed contract rather than a habit. Interoperability is now good enough that this is a real option, not a compromise.

The mechanisms are documented. Every Iceberg table in Unity Catalog is reachable through the Iceberg REST Catalog API by engines such as Spark, Flink, and Trino, and Databricks reads foreign Iceberg tables managed by other catalogs, Snowflake Horizon Catalog among them, read-only through Lakehouse Federation (Iceberg in Databricks). Snowflake reads and writes Snowflake-managed and externally managed Iceberg tables alike (Iceberg tables). Storage can be shared rather than copied: a Unity Catalog external location typed as OneLake lets Databricks write managed tables into a Fabric workspace path (OneLake external locations), and an Azure Databricks catalog appears in Fabric as a read-only mirrored item with no data movement (mirroring Unity Catalog).

What makes it work is a governed boundary with an owner, and the failure mode is a seam nobody designed. Both are in Databricks and Fabric together and where governance leaks, where the data crosses correctly and the permissions do not. If your second platform is an AI platform, the equivalent question is in Fabric and Foundry solve different problems.

How do you actually decide?

Answer six questions in writing, in this order. They point at a platform more reliably than any comparison table, including the one in this post.

1. What is the workload at the edge of your estate? Name the one thing that would be hard on a generic platform: streaming at scale, external distribution, thousands of Power BI consumers, GPU work beside the warehouse. This question alone resolves many decisions.
2. What shape is your compute usage? Spiky and scheduled favours consumption billing, interactive with real idle gaps favours per-second warehouses, and broad multi-team usage favours a fixed capacity you can forecast.
3. Who consumes the output, and where do they already work? If the answer is several thousand people in Excel and Teams, the consumption layer is close to decided whatever does the processing.
4. Do you send data outside your organisation? If it is more than a monthly file, sharing without copies is worth choosing for rather than rebuilding.
5. What is your team’s real skill distribution, and what will you pay to change it? Not the skills on the job description. A Spark-native platform in a team of SQL analysts is a training budget and a hiring plan, and both belong in the business case.
6. What must return the identical number afterwards, and who signs that off? Name the reports and the period. This converts a migration from a project into a deliverable.

Most estates that run this honestly land on one primary platform plus a designed consumption or distribution seam, not on a single-vendor estate and not on three platforms nobody governs.

Where this goes wrong

Choosing on a feature matrix. The symptom is a decision document where every row ticks all three platforms and the recommendation rests on the last two rows. The cause is comparing at the level of the common workload. Compare on the edge workload.

Choosing on a vendor benchmark. The symptom is a proof of concept showing one platform faster on a query nobody runs. The cause is that published benchmarks are tuned and yours will not be. Test your own worst query at your own concurrency and treat the result as directional.

Sizing a fixed capacity from a peak. The symptom is either throttling at month end on Fabric or a capacity three times what the average workload needs. The cause is missing that smoothing lets you size on average while one enormous background job still exhausts the budget.

Forgetting the second bill. The symptom is a Databricks forecast at half the real cost. The cause is that classic compute charges DBUs and cloud infrastructure separately. Budget both, or compare serverless rates, which include the infrastructure.

Minimising auto-suspend on Snowflake. The symptom is a credit bill that rises after a cost-saving change. The cause is the one-minute minimum on every resume. Match auto-suspend to the gaps in the query pattern rather than driving it to the floor.

Common questions

Is Databricks better than Snowflake in 2026?

They are strongest at different things, so a single ranking is not useful. Databricks is built around Spark, declarative pipelines, and a model lifecycle governed in the same catalog as the data. Snowflake is built around SQL warehousing and is the stronger of the two at sharing data outside your organisation without copies. Both read and write Iceberg, so the table format is no longer the differentiator it was.

Can I run Databricks and Fabric together instead of choosing?

Yes, and many organisations do. Azure Databricks tables appear in Fabric as a read-only mirrored catalog with no data movement, with Databricks keeping every write. The catch is that Unity Catalog permissions do not carry across that boundary, so the Fabric workspace needs its own access model. Design the seam before you rely on it.

Which platform is cheapest?

The one whose billing model matches your usage shape, which is why the question has no general answer. Databricks units reward short, bursty, scheduled work. Snowflake credits reward interactive query with real idle periods. A fixed Fabric capacity rewards broad multi-team usage and is the easiest to forecast. Differences between platforms are usually smaller than the difference between a well-run and a badly-run implementation of any one of them.

Do we need a lakehouse, or is a warehouse enough?

If your data is tabular, arrives on a schedule, and is consumed by SQL and dashboards, a warehouse is enough and simpler. Lakehouse capabilities earn their keep with semi-structured data at volume, streaming ingestion, or machine learning that needs the raw layer as well as the modelled one.

How long does a platform migration take?

Long enough that the answer should come from your own inventory rather than a vendor estimate. Count sources, pipelines, stored procedures, reports, and security roles, then mark which have an owner who can confirm the intended behaviour. The ones with no owner are the schedule risk, because parity cannot be signed off on logic nobody can explain.

Next steps

Write one-line answers to the six questions above and circulate them before anyone builds a proof of concept. Most platform disagreements are disagreements about constraints, and they resolve once the constraints are on a page both parties can argue with.

Then read Databricks and Fabric together and where governance leaks if your answer involves two platforms, and data architecture patterns and how to choose one for the modelling decisions that follow. More engineering writing sits in the Signals index.

Zorost runs these evaluations and the migrations that follow as a trusted Databricks partner, which is also why the parity report is written before the first pipeline is ported: a platform that returns different numbers has not been migrated, it has been replaced.