Databricks alternatives: where to go and how to migrate without a rewrite
Eight destinations, one per reason for leaving, plus an eight-step migration plan.
The short answer: Snowflake if your work is mostly SQL and BI, BigQuery if you're on Google Cloud and want zero clusters, Microsoft Fabric if your company runs on Power BI and Azure, Amazon EMR if you want to keep your Spark code on AWS for less, Starburst or Dremio if you'd rather leave your files where they are and only swap the engine, ClickHouse Cloud for fast customer-facing dashboards, and MotherDuck if your data fits in a few hundred gigabytes. One piece of good news first: your Delta tables are Parquet files in your own storage. BigQuery, Snowflake, Fabric, Starburst and DuckDB can all read them. The real work sits elsewhere, in Databricks-specific code and in access controls. We compared the eight destinations in this guide and checked their prices on each vendor's own pages in 2026.
The ranking is editorial: a sponsored spot is always labeled on its card, and no affiliate link changes a rating.
Why teams leave Databricks, and where it hurts
Databricks is still the benchmark for machine learning and heavy Spark processing. Teams don't leave because the product is bad. They leave because they're paying for a platform built for terabytes while their actual need is somewhere else. Six reasons keep coming up, and each one points to a different destination.
Two bills instead of one
Databricks charges DBUs (Databricks Units, a unit of compute per hour), and your cloud bills the virtual machines on top, except on serverless. On Azure Databricks Premium in US East, a DBU costs $0.30 for Jobs compute and $0.55 for All-Purpose. A forgotten interactive cluster runs up two meters at once. On r/dataengineering, one team said its bill came in at twice the estimate, and that estimate already had a 50% buffer built in.
Serverless SQL gets expensive behind dashboards
On Azure Databricks Premium in US East, a serverless SQL DBU costs $0.70, versus $0.22 on SQL Classic, with compute included on serverless. Keep it up all day behind internal dashboards, or behind dashboards your customers see, and the line item grows fast. One team holding a $1,000-a-month budget ended up reading its Delta tables with delta-rs and DuckDB for its real-time dashboards instead.
Your data is too small for Spark
Spark exists to spread work across many machines. At 100 to 200 GB total and 1 GB a day, a single node usually does the job. In an r/dataengineering thread about a 200 GB warehouse, the top answer put it bluntly: at that size you're paying for distributed compute you won't use. That's the classic case where a SQL database or DuckDB costs a fraction of the price.
Local testing is painful
One team described a 10 to 20 minute loop to test a single change, because everything had to be deployed to Databricks first. Replies pointed out that Databricks Asset Bundles with pytest fix part of that. Still, if your team wants local unit tests and no notebooks, a simpler SQL engine with dbt is often the more comfortable home.
Your company picked another cloud, or Power BI
Plenty of exits aren't technical. Leadership standardizes on Microsoft 365 and Power BI, and Fabric becomes the default. Or the company moves to Google Cloud, and BigQuery follows. Then the question isn't which tool is best, it's how to migrate without losing six months.
Free Edition isn't a small paid plan
Databricks retired Community Edition in 2025 and replaced it with Free Edition. It costs nothing, but it's limited to non-commercial use: one SQL warehouse at 2X-Small, 5 concurrent job tasks, no R or Scala, and no SLA. A small business hoping to stay free for real work has to pay, or move to a tool with a genuine commercial free tier (BigQuery, MotherDuck, Starburst).
You're leaving because… go with…
Start with what you actually do on Databricks today. If it's 90% SQL and dashboards, your destination is not the same as if you train models every night.
Managed SQL warehouse, per-second credits, tooling that converts Databricks SQL.
You're on Google Cloud and done managing clustersBigQueryNo servers, 1 TiB of free queries a month, reads Delta tables in place.
Your company runs on Power BI and AzureMicrosoft FabricCan mirror your Azure Databricks catalog without copying data.
You want to keep Spark on AWS for lessAmazon EMRServerless Spark billed per vCPU and GB, no DBUs.
You want to keep your files and swap the SQL engineStarburstManaged Trino, Delta Lake connector, free tier.
You want an open Iceberg lakehouse with simple pricingDremio$0.20 per DCU, $400 trial with no card.
Customer dashboards must answer in under a secondClickHouse CloudFast columnar analytics engine, $300 trial credits.
Your data fits in a few hundred GBMotherDuckDuckDB in the cloud, free up to 10 GB and 10 compute hours.
Databricks alternatives, one by one
Each card covers why you'd move to that tool, who it's for, who it isn't for, its main limit, how to migrate from Databricks, and what it costs. Prices are list prices from each vendor's site in 2026, in US dollars, using a US region where the vendor publishes one.
The tools
Snowflake: when your work is mostly SQL
SQL and BIWhy move to Snowflake. It's the managed SQL warehouse closest to what Databricks SQL does, minus clusters and VMs. You create a virtual warehouse, size it, and it pauses when nobody's using it. Snowflake even documents migrating from Databricks.
Who it's for. Data teams whose daily work is SQL, dbt models and dashboards, with some Python on the side.
Who it isn't for. A team that trains heavy GPU models every night, or writes mostly Scala. It will lose more than it gains.
The catch. In AWS US East, an on-demand credit costs $2.00 on Standard, $3.00 on Enterprise and $4.00 on Business Critical. An X-Small warehouse uses 1 credit an hour, and storage runs $23 per TB per month. A badly tuned warehouse that never suspends costs as much as a forgotten Databricks cluster.
How to migrate. For SQL, SnowConvert AI converts the SQL behind your tables and views written in Spark SQL or Databricks SQL. For PySpark, Snowpark Connect runs your Spark code on Snowflake's engine with no Spark cluster, so you don't have to rewrite everything at once. For data, Snowflake can create an Iceberg table on top of Delta files in object storage: read your tables in place during the transition, then copy the busiest ones into native tables. Watch the dialect: Netlify had to swap if() for iff() and collect_list() for array_agg(), and dividing by zero throws an error in Snowflake where Databricks returns NULL.
- Credit
- $2.00 (Standard, AWS US East)
- Storage
- $23 per TB per month
- Billing
- per second, suspended warehouse is free
- Catch
- warehouses left running
BigQuery: when you never want to size a cluster again
ServerlessWhy move to BigQuery. There's nothing to start or stop. You write a query, Google runs it, you pay for the bytes scanned. For a team tired of tuning cluster sizes and auto-termination, it's the cleanest break.
Who it's for. Companies already on Google Cloud, teams that land Google Analytics 4 or Google Ads data, and teams that query in bursts rather than all day.
Who it isn't for. A team whose data all lives on AWS or Azure. Moving terabytes out of another cloud costs money, and you add a vendor.
The catch. On-demand pricing is $6.25 per TiB scanned, after the first free TiB each month. A SELECT * on a big unpartitioned table hits your wallet directly. Past a certain volume you move to capacity pricing ($0.06 per slot-hour on Enterprise in the US) and have to learn to size it. Active storage is about $0.023 per GiB per month, with 10 GiB free.
How to migrate. If your Delta tables sit in Google Cloud Storage, BigQuery reads them as BigLake external tables (CREATE EXTERNAL TABLE), deletion vectors included, and picks up schema changes on its own. You can point dashboards at BigQuery before moving a single file, then convert the most-read tables to native ones.
- Free
- 1 TiB of queries and 10 GiB a month
- Paid
- $6.25 per TiB scanned
- Capacity
- $0.06 per slot-hour (Enterprise, US)
- Catch
- one sloppy query can cost a lot
Microsoft Fabric: when your company lives in Power BI
Microsoft stackWhy move to Fabric. Fabric puts the lakehouse, the warehouse, Spark, pipelines and Power BI under one capacity. Lakehouse tables are Delta files in OneLake, the same format Databricks uses, so your files change address, not shape. For a company standardized on Microsoft, that's one contract and one console.
Who it's for. Finance and BI teams that already run Power BI and Azure and want the data closer to the reports.
Who it isn't for. A team with unpredictable compute spikes that can't afford to wait. Fabric answers overload by slowing down, not by billing more.
The catch. You pay for a running capacity, not per query. An F2 in East US is about $0.18 per CU-hour, so about $262.80 a month at 730 hours (our math); a 1- or 3-year reservation saves about 41%. When the capacity is saturated, Microsoft throttles in stages: past 10 minutes of future capacity used, interactive requests get a 20-second delay; past an hour, they're rejected; past 24 hours, everything is. Overage billing exists but costs three times the normal rate. And below F64, everyone who publishes or views a report needs a Power BI Pro license.
How to migrate. On Azure Databricks, Fabric can mirror your Unity Catalog: only the structure is copied, and the data is read through shortcuts. Tables, materialized views and streaming tables are mirrored; views and metric views don't show up, nor do external tables that aren't Delta. For the rest, create OneLake shortcuts to ADLS Gen2 or S3; a Delta folder placed under Tables is recognized as a table. Table names with spaces won't work.
- Capacity
- F2 about $262.80 a month (East US, our math)
- Reservation
- about 41% off
- Storage
- OneLake $0.026 per GB per month
- Catch
- throttling when capacity is full
Amazon EMR: when you want Spark without DBUs
Spark on AWSWhy move to EMR. Your PySpark code runs as is, or close to it, because EMR runs Apache Spark. The DBU layer disappears: on EMR Serverless you pay for the vCPU and memory you use, per second, with a one-minute minimum. On EMR on EC2 you pay the EMR fee plus the instance, and Spot instances can save up to 90% versus On-Demand.
Who it's for. Data engineering teams on AWS with heavy, regular Spark pipelines and someone to own orchestration (Airflow, Step Functions).
Who it isn't for. Analysts who want notebooks, a catalog and dashboards out of the box. EMR is an engine, not a platform.
The catch. Everything Databricks wrapped around Spark is yours to rebuild: catalog (Glue), permissions (Lake Formation), notebooks, alerting, deployment. On Reddit, an engineer planning exactly that setup got warned about Lake Formation permission complexity and the orchestration work landing on the team. Databricks-only features like dbutils and Delta Live Tables don't exist here.
How to migrate. List your jobs, then replace dbutils.fs calls with S3 calls and dbutils.secrets with AWS Secrets Manager. Turn notebooks into versioned Python scripts. Run each job on EMR Serverless next to Databricks and compare outputs before cutting over. In US East, a vCPU-hour costs $0.052624 and a GB-hour of memory $0.0057785.
- Serverless
- $0.052624 per vCPU-hour (US East)
- Memory
- $0.0057785 per GB-hour
- Billing
- per second, 1-minute minimum
- Catch
- you rebuild the platform around Spark
Starburst Galaxy: when you want a new engine, not new storage
Open lakehouseWhy move to Starburst. Starburst Galaxy is a managed service built on Trino, a SQL engine that queries files where they live. Your Delta tables stay in S3 or ADLS; only the compute changes. It's the lowest-risk exit for your data.
Who it's for. Teams with data spread across a lake, operational databases and other warehouses that want to query it all in SQL without copying it.
Who it isn't for. A team doing mostly machine learning in Python notebooks. Starburst is a SQL engine.
The catch. Pricing is in credits: Pro starts at $0.50 a credit, Enterprise at $0.75, and a 2-worker cluster uses 12 credits an hour, so $6 an hour on Pro. Credit burn is the same on every tier; only the price per credit changes. The Delta Lake connector can't read Databricks views, but it can read managed and external tables through the Unity metastore.
How to migrate. Point the Delta Lake connector at your storage, recreate your views in Trino SQL (they don't come along), then repoint dashboards. The 30-day trial includes $500 of compute and Enterprise features; after that, the account drops to the free tier with up to 3 clusters.
- Free
- up to 3 clusters
- Paid
- Pro from $0.50 per credit
- Trial
- 30 days, $500 of compute
- Catch
- can't read Databricks views
Dremio: when you want an open lakehouse with readable pricing
IcebergWhy move to Dremio. Dremio queries your data lake in SQL and bets on Apache Iceberg, the open table format that Snowflake, Starburst and Spark also read. If your reason for leaving is vendor lock-in, it's a solid way out.
Who it's for. Teams that want a fast SQL engine on their own files, with pricing simple enough to explain to finance.
Who it isn't for. A team that wants pipelines, notebooks and machine learning in one tool. Dremio covers querying and the semantic layer, not model training.
The catch. Dremio Cloud costs $0.20 per DCU (Dremio Compute Unit), metered on engine size and run time: a 20-DCU engine running for 10 hours uses 200 DCUs, or $40. Self-hosted Enterprise is quote-only, and the free Community Edition is yours to run.
How to migrate. Start with your most-read tables: convert them to Iceberg or expose them as they are, repoint one dashboard and compare numbers. The trial gives $400 of credits over 30 days with no credit card, enough for a real pilot.
- Paid
- $0.20 per DCU
- Trial
- $400 over 30 days, no card
- Free
- self-hosted Community Edition
- Catch
- no built-in machine learning
ClickHouse Cloud: when dashboards have to answer instantly
Fast analyticsWhy move to ClickHouse. ClickHouse is a columnar database built for fast aggregations over large event volumes. For a dashboard your customers open, or log analytics, it's often faster and cheaper than a SQL warehouse kept running all day.
Who it's for. SaaS companies showing usage stats to customers, product teams analyzing events, and teams blocked by the cost of dashboards on Databricks.
Who it isn't for. Heavy jobs with lots of joins across big tables, and machine learning. Keep Spark or a warehouse for that.
The catch. ClickHouse wants you to design the data model up front (sort key, partitions); it's less forgiving than a general-purpose warehouse. Pricing is per compute unit (8 GiB RAM and 2 vCPU) per hour: on Enterprise in AWS us-east-1 that's $0.39030, plus $25.30 per TB per month for storage. The Basic tier caps storage at 1 TB.
How to migrate. Don't move everything. Move only the tables that serve fast dashboards, fed from your lake. Export the history once as Parquet, then feed ClickHouse continuously from your ingestion pipeline. The trial gives $300 of credits over 30 days.
- Trial
- $300 over 30 days
- Paid
- usage-based, no monthly minimum
- Compute
- $0.39030 per unit-hour (Enterprise, AWS us-east-1)
- Catch
- data model to design up front
MotherDuck: when your data fits on one server
Small dataWhy move to MotherDuck. MotherDuck is DuckDB in the cloud: a very fast single-node SQL engine with sharing and a web UI. If your data is a few hundred gigabytes, it's often the simplest way to cut the bill.
Who it's for. Startups and small data teams with 100 to 500 GB, mostly analytical needs, and a taste for testing locally in DuckDB before publishing.
Who it isn't for. Teams with tens of terabytes and complex Spark pipelines, or large enterprises that need fine-grained governance.
The catch. Lite is free but capped at 3 users, 10 GB of storage and 10 compute hours a month. Business is $250 per org per month plus usage: $0.60 per CU-hour on Pulse compute and $0.04 per GB-month of storage. It's a young product next to Snowflake or BigQuery.
How to migrate. DuckDB's delta extension reads Delta tables straight from S3 with delta_scan(). Read your tables in place, compare results, then load the busiest ones into MotherDuck. Business has a 7-day trial with no card.
- Free
- Lite: 3 users, 10 GB, 10 compute hours
- Paid
- $250 a month + usage
- Compute
- $0.60 per CU-hour
- Catch
- built for modest volumes
The 8 alternatives compared
The table shows each tool's billing unit and entry price, then what actually changes when you come from Databricks. The unit matters more than the sticker: a running capacity, bytes scanned and per-second credits react very differently to a team that queries all day.
| Billing unit and entry price | What changes coming from Databricks | |
|---|---|---|
| DatabricksWhere you start | DBUs + cloud VMs; Azure Premium US East: Jobs $0.30, All-Purpose $0.55, SQL Serverless $0.70 per DBU | Full Spark, ML and SQL platform; two bills outside serverless |
| SnowflakeSQL and BI | Per-second credits; $2.00 a credit on Standard (AWS US East) | No clusters; SQL needs edits, PySpark via Snowpark Connect |
| Google BigQueryServerless | $6.25 per TiB scanned, first TiB free each month | Nothing to size; reads Delta tables in place |
| Microsoft FabricMicrosoft stack | Capacity; F2 about $262.80 a month (East US, our math) | Delta kept in OneLake; throttling instead of overspend |
| Amazon EMRSpark on AWS | $0.052624 per vCPU-hour + $0.0057785 per GB-hour (Serverless, US East) | Spark code kept; catalog, permissions and notebooks to rebuild |
| Starburst GalaxyOpen lakehouse | Free up to 3 clusters; Pro from $0.50 a credit | Files untouched, Trino engine; views to recreate |
| DremioIceberg | $0.20 per DCU; $400 trial | Files untouched; no built-in ML |
| ClickHouse CloudFast analytics | $0.39030 per unit-hour (Enterprise, AWS us-east-1); $300 trial | Faster dashboards; data model to rethink |
| MotherDuckSmall data | Lite free; Business $250 a month + usage | Single node, much cheaper; not for huge volumes |
List prices in US dollars, before tax, as published by each vendor in 2026, subject to change. Outside serverless, cloud VMs are billed on top of Databricks DBUs. Always check against your real volume.
Migrating off Databricks in eight steps
The idea: the new platform runs next to Databricks, on the same files where possible, until the numbers match. You only switch Databricks off at the end. Plan on a few weeks for a small team and several months for hundreds of jobs.
The steps
Inventory what actually runs
Week 1List jobs, scheduled notebooks, SQL warehouses, Delta Live Tables pipelines and every dashboard reading from Databricks. Your Databricks bill, broken down by cluster and warehouse, tells you what costs the most. Start there.
Tag each item as pure SQL, PySpark or machine learning. That split alone tells you which destination is realistic.
- Time
- two to three days
- Output
- job list ranked by cost
Find the Databricks-only code
Week 1Search your repo for dbutils (files, secrets, widgets, dbutils.notebook.run), magic commands like %run and %sql, spark.databricks.* settings and Unity Catalog three-level names (catalog.schema.table). No other platform understands them.
Wrap those calls in a small module you own (read a file, read a secret). On migration day you change that module, not a hundred notebooks.
- Time
- one to two days
- Tool
- repo-wide search
Decide whether the data moves
Week 2Your Delta tables are Parquet files plus a transaction log in your own storage. BigQuery (BigLake), Snowflake (Iceberg tables over Delta files), Fabric (OneLake shortcuts), Starburst and DuckDB can read them. Read them in place first: move the compute before the data.
Note the Delta features each table uses. Newer ones like deletion vectors and column mapping aren't read by every engine.
- Time
- two days
- Risk
- Delta feature the new engine can't read
Rebuild access controls
Week 2Export Unity Catalog permissions (who reads what, column masks, row filters) before touching anything. They don't transfer anywhere automatically.
Recreate them in the new tool by group, not by person. It's the most underestimated step and the only one with real data-leak risk.
- Time
- two to five days
- Risk if rushed
- sensitive data open to everyone
Pilot one domain
Weeks 3 and 4Pick one full domain, finance for example: its sources, models and two or three dashboards. Migrate it without refactoring the SQL. Netlify made that its first rule: rewriting while migrating makes every mismatch impossible to explain.
Track the pilot's bill over two real weeks. It's the only number that matters for what comes next.
- Time
- two weeks
- Output
- real cost over two weeks
Run both pipelines side by side
Weeks 4 to 6Run old and new in parallel. Compare row counts, then daily sums on key columns (revenue, order counts). Mismatches usually come from the dialect: division by zero, time zones, identifier casing.
Only move to the next domain once the gap is zero or explained.
- Time
- one to two weeks per domain
- Check
- daily sums
Cut dashboards over
End of projectStart with the most-viewed reports. Netlify moved its 20 most-used reports first and archived the ones nobody opened. Keep table and view names identical so links and filters keep working.
Warn users the day before and keep the old report read-only for a week.
- Time
- one week
- Tip
- archive dead reports
Shut Databricks down cleanly
Final weekStop jobs, then SQL warehouses, then clusters. Revoke access tokens and service principals. Keep the storage: your Delta tables stay readable without Databricks, and they're your archive.
Check when your commitment ends: a committed-use discount gets paid in full, even if you stop consuming.
- Time
- half a day
- Keep
- table storage
Is your tool missing from this page? Email us: hello@hackceleration.com
What makes a Databricks migration fail
Failed migrations almost never come from the platform you picked. They come from the same six oversights, which show up again and again in forums and team write-ups.
Paying for two platforms too long
Running both is necessary, but it doubles the bill. Set an end date per domain and switch that domain's Databricks jobs off as soon as it's validated.
Assuming PySpark ports as is
Plain DataFrame code often does. dbutils, widgets and Delta Live Tables never do. Snowpark Connect and EMR help, but every job still has to be rerun and compared.
Forgetting permissions
Unity Catalog doesn't export itself. A payroll table readable by the whole company after cutover is the incident that kills a project.
Choosing on list price
A DBU, a credit and a TiB scanned don't compare. Only a two-week pilot on your real volume gives you a trustworthy number.
Undersizing Fabric
A cheap F2 saturates fast. When it does, users wait 20 seconds, then get rejected. Size for your peak hours, not your average.
Ignoring the commit
If you signed a committed-use deal with Databricks, unused spend is still owed. Line up the end of the migration with the end of the contract.
- Jobs, notebooks, warehouses and dashboards ranked by cost
- dbutils, %run and Unity Catalog names found
- Delta features noted for each table
- Unity Catalog permissions exported
- Destination chosen by SQL, Spark and ML share
- One-domain pilot with a real bill
- Row counts and daily sums compared
- Most-viewed reports cut over first
- Jobs, warehouses and clusters stopped, tokens revoked
- Databricks commitment end date checked
Databricks alternatives: frequently asked questions
What is the cheapest alternative to Databricks?
For small data, MotherDuck: Lite is free up to 10 GB and 10 compute hours a month, and Business starts at $250 a month. For bursty querying, BigQuery gives you 1 TiB of free queries every month. To keep Spark, EMR Serverless drops the DBU layer. The cheapest option depends on your volume, so run a pilot before you sign.
Can I keep my Delta Lake tables if I leave Databricks?
Yes. Delta is an open format: Parquet files plus a transaction log in your storage. BigQuery reads them as BigLake tables, Snowflake as Iceberg tables built on Delta files, Fabric through OneLake shortcuts, and DuckDB with its
deltaextension. Just check that the engine supports the features you use, like deletion vectors.Is Snowflake cheaper than Databricks?
It depends on the workload. For SQL and BI, Snowflake is often easier to keep under control: an X-Small warehouse uses 1 credit an hour ($2.00 on Standard in AWS US East) and suspends when idle. For heavy Spark and machine learning, Databricks is often the more efficient choice. Both vendors publish case studies going in both directions.
Is Databricks Free Edition enough for a small business?
Not for production. It's limited to non-commercial use, with one 2X-Small SQL warehouse, 5 concurrent job tasks and no SLA. It's good for learning, or for measuring how a job performs, as one Reddit thread suggests, but not for running the business.
How long does a Databricks migration take?
A few weeks for a small team doing mostly SQL, several months for hundreds of Spark jobs. Netlify moved close to 500 dbt models in a matter of weeks by freezing every other project and banning refactoring during the move.
Does Microsoft Fabric replace Azure Databricks?
For BI and warehousing, often yes, especially since Fabric can mirror your Unity Catalog without copying data. For advanced ML and large, spiky Spark jobs, many teams keep both. Keep the behavior difference in mind: Fabric slows down and then rejects requests when capacity is full, while Databricks keeps running and bills more.
How do I replace dbutils outside Databricks?
There's no universal drop-in.
dbutils.fsbecomes calls to your storage (S3, ADLS, GCS),dbutils.secretsbecomes your cloud's secret store, anddbutils.notebook.runbecomes your orchestrator. The easiest path is to wrap those calls in one module before you migrate.Should I leave Databricks or cut the bill first?
Try three settings first: job clusters instead of All-Purpose clusters ($0.30 versus $0.55 per DBU on Azure Premium), a short auto-termination, and per-cluster budgets. If the bill is still too high or your data is small, migrating makes sense. To compare warehouses, read our data warehouse ranking, and for ingestion, our ETL tools comparison.
Get the next migration guide in your inbox
One tool to leave, one destination, one migration plan. Nothing else.