A comparison of the three big data platforms for Nordic companies: cost model, skills, Power BI and lock-in.
In short
Choose Microsoft Fabric if you are a Microsoft and Power BI shop that wants one SaaS product with capacity-based pricing. Choose Databricks if data engineering, Spark and machine learning are central and you want to run across clouds. Choose Snowflake if SQL analytics and data sharing dominate. All three store open table formats, so lock-in is manageable.
The three platforms overlap more every year, and their marketing claims sound alike. The useful differences sit in how you pay, which skills your team needs, how well each one serves Power BI, and how hard it would be to leave.
This comparison is written by Devies, a Gothenburg-based product and engineering consultancy that builds and runs data platforms for Nordic companies. It is a vendor-neutral starting point, not a substitute for a proof of concept on your own data.
What are Microsoft Fabric, Databricks and Snowflake?
Microsoft Fabric, Databricks and Snowflake are cloud data platforms that store, transform and serve analytics data, but each comes from a different starting point.
Microsoft Fabric is Microsoft's software-as-a-service analytics platform. It bundles data engineering, a warehouse, real-time analytics, Data Factory pipelines and Power BI in one product, billed through a shared capacity. Every Fabric tenant includes OneLake, a single data lake for the whole organisation.
Databricks is a data and AI platform built around Apache Spark and the Delta Lake table format. It runs on Azure, AWS and Google Cloud, and it popularised the lakehouse.
Snowflake is a cloud data platform that started as a SQL data warehouse and has grown into data engineering, data sharing and AI features. It also runs on all three major clouds.
A lakehouse is an architecture that keeps data as open-format files in cheap object storage while offering warehouse features such as tables, transactions and SQL on top. All three vendors now support some form of it, which is why the old "warehouse versus lake" argument matters less than it used to.
Which criteria should decide the choice?
The deciding criteria are your existing cloud and BI stack, the skills you have, the cost model you can predict, and how much freedom you need to change engines later.
Work through these questions before looking at feature lists:
- Where does your reporting live? If Power BI is the company standard, how each platform serves Power BI matters more than benchmark results.
- Which skills does the team have? SQL-first analysts, Spark and Python engineers, and low-code integrators each fit a different platform.
- How do you want to pay? A fixed capacity you size and reserve, or consumption you pay for per query and per cluster minute.
- Which cloud are you committed to? A Microsoft enterprise agreement, an AWS commitment or a multi-cloud policy narrows the field.
- How heavy is machine learning? Occasional models are possible everywhere. A team training and serving models daily has stronger needs.
- What is your exit plan? Which table format your data is stored in, and who owns the storage account, decide how hard a future move will be.
If you are choosing a platform to support AI, start with the use cases rather than the tooling. Our guide on how to prioritise AI use cases shows how to work out which data you actually need first.
How do the three platforms compare?
The three platforms differ most in pricing model, primary skill set and depth of Power BI integration, and least in raw capability.
The table summarises the general picture as of October 2026. Features change quickly, so treat it as a starting point and verify the details that matter to you.
Criterion
Microsoft Fabric
Databricks
Snowflake
Delivery model
Microsoft Fabric
SaaS inside the Microsoft tenant
Databricks
Managed platform in your Azure, AWS or Google Cloud account
Snowflake
SaaS on AWS, Azure or Google Cloud
Cost model
Microsoft Fabric
Capacity (F SKUs) shared by all workloads; can be paused
Databricks
Consumption-based compute, plus cloud infrastructure
Snowflake
Consumption-based compute (credits) plus storage
Core skills
Microsoft Fabric
SQL, Power BI, low-code pipelines, some Spark
Databricks
Python, Spark, SQL, MLOps
Snowflake
SQL first, Python available
Power BI
Microsoft Fabric
Native, including Direct Lake mode
Databricks
Via connector or Fabric mirroring
Snowflake
Via connector or Fabric integration
Data ingestion
Microsoft Fabric
Built-in Data Factory pipelines and dataflows
Databricks
Own tools, or Azure Data Factory and similar
Snowflake
Own tools, or external ETL tools
Open formats
Microsoft Fabric
Delta Parquet and Iceberg in OneLake
Databricks
Delta Lake, Iceberg via UniForm
Snowflake
Native tables, plus Iceberg tables
Typical fit
Microsoft Fabric
Microsoft-centred mid-sized companies
Databricks
Engineering-heavy and ML-heavy teams
Snowflake
SQL analytics and data sharing at scale
On Power BI, Fabric has a structural advantage. Direct Lake is a Power BI storage mode that loads Delta tables from OneLake into memory without copying them, and it requires a Fabric capacity. Databricks and Snowflake both work well with Power BI through Import or DirectQuery, but you manage refreshes and query costs on two systems instead of one.
On lock-in, the picture is better than it was. Microsoft documents that OneLake stores tables in Delta Parquet or Iceberg, "two open standards that any tool can read". Databricks open-sourced Unity Catalog under the Apache 2.0 licence in June 2024. Snowflake supports Apache Iceberg tables whose files sit in cloud storage you manage. The real lock-in today lives in pipelines, security models and business logic, not in file formats.
Which platform fits which scenario?
The right platform usually follows from your dominant workload and existing contracts, so map your situation to the closest scenario.
Mid-sized company on Microsoft 365 and Power BI. You have a small data team, reports built by analysts, and an existing Microsoft agreement. Microsoft Fabric is usually the shortest path: one bill, one security model and native Power BI. Watch capacity sizing, because all workloads share the same capacity units.
Engineering-led company with machine learning in production. Several data engineers work in Python and Spark, and models are trained and deployed regularly. Databricks fits this team well, and its tooling for notebooks, jobs and model management is mature. Budget for the platform skills it requires.
SQL-heavy analytics with many consumers or external data sharing. Analysts work mainly in SQL, query volumes vary a lot, and you share data with partners. Snowflake's separation of storage and compute and its data sharing features fit this pattern.
Already on Azure Synapse or Azure Data Factory. Many Nordic companies run pipelines in Azure Data Factory feeding a Synapse or SQL warehouse. Moving to Fabric is the most natural step, but it is still a migration. Pipelines, notebooks and security need to be rebuilt or tested, not just copied.
Mixed setups are common and legitimate. Fabric can mirror an Azure Databricks catalog and work with Snowflake data, so choosing one engine for transformations and another for reporting is a valid design if you can justify the extra operating cost.
What does migration involve, and how do you reduce lock-in?
Migration mostly means moving pipelines, business logic and permissions rather than data, so plan it in layers and keep your core data in open formats.
A medallion structure helps. Raw data lands in a bronze layer, is cleaned in silver and is shaped for business questions in gold. If bronze and silver are stored as Delta or Iceberg tables in storage you control, a later move to another engine affects the compute and the gold layer, not your entire history.
Plan the migration in this order:
- Inventory: list sources, pipelines, schedules, reports and who owns each one.
- Pilot one domain: move one subject area end to end, including permissions and Power BI reports.
- Run in parallel: compare numbers between the old and new platforms before switching users.
- Retire deliberately: turn off old pipelines only when owners have signed off.
One dated fact affects many Power BI customers. As of October 2026, Microsoft's Premium migration guide states that Power BI Premium per-capacity P SKUs are being retired at the end of each customer's agreement term, and new deployments should use Fabric F SKUs. If your P SKU renewal is near, that is a natural moment to make the platform decision rather than renew by default.
Keep reading
From our work
Client Case: Stena LineStena Line modernised its Azure data platform - improving Power BI reliability, reducing pipeline runtimes and scaling with medallion architecture.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
Is Microsoft Fabric cheaper than Databricks or Snowflake?
It depends on your workload, not on list prices. Fabric uses a capacity that you size and can pause, so costs are predictable but you pay for headroom. Databricks and Snowflake charge mainly for compute you consume, which suits variable workloads but needs monitoring to avoid surprises. Run a two-to-four week proof of concept with your real data and reports, then compare the measured cost per month.
Can we use Power BI with Databricks or Snowflake?
Yes. Power BI connects to both through Import and DirectQuery, and many companies run that setup successfully. The difference is that Fabric adds Direct Lake, which reads Delta tables in OneLake without copying them into the Power BI model. With Databricks or Snowflake you manage refresh schedules and query costs in two places, which is workable but adds operational effort.
Should we replace Azure Data Factory when moving to Fabric?
Not necessarily on day one. Azure Data Factory remains a separate Azure service, and Fabric includes its own Data Factory experience with pipelines and dataflows. Many teams keep existing Azure Data Factory pipelines running while they move one domain at a time into Fabric. Plan the switch per pipeline, test the results in parallel, and retire old pipelines only when the owners have signed off.
How do we avoid vendor lock-in with a data platform?
Keep your core data in open table formats such as Delta Lake or Apache Iceberg, in storage your organisation controls, and document business logic outside proprietary tools where possible. All three platforms support at least one open format. The harder lock-in is in pipelines, security rules and semantic models, so keep these version-controlled and documented, and assume each would need rebuilding in a migration.
Sources
- Microsoft Learn: OneLake, the unified data lake
- Microsoft Learn: Direct Lake overview
- Microsoft Learn: Pause and resume your Fabric capacity
- Microsoft Learn: Power BI Premium migration decision guide
- Databricks: Databricks open sources Unity Catalog (12 June 2024)
- Snowflake documentation: Apache Iceberg tables
- Devies: Data Hub, Data Foundation Platform, Stena Line client case (devies.se)
