Migration
Oracle Exadata to Databricks migration: replacing the hardware refresh
How to move a data warehouse off Oracle Exadata to Databricks before the next hardware refresh: what replaces Smart Scan, HCC and partitioning, moving tens of terabytes, and keeping OLTP workloads separate.
Hemant Walchale
· 2 min read
An Exadata hardware refresh is one of the largest line items in many data budgets, and it forces the question: refresh again, or move the warehouse to the cloud? Moving to Databricks replaces fixed, engineered hardware with elastic compute and open storage. This guide covers what is specific to leaving Exadata; for converting PL/SQL and Oracle data types, see our Oracle to Databricks guide.
This is the approach we recommend.
1. Separate the warehouse from everything else
Exadata machines often host the warehouse alongside operational databases. Map which databases, schemas and workloads run on the machine, decide what moves to Databricks (analytics, reporting, data science) and what needs a different home (OLTP), and plan both, because the hardware is only retired when it is empty.
2. Replace Exadata features, don’t copy them
| Exadata and Oracle feature | On Databricks |
|---|---|
| Smart Scan, storage indexes | Delta data skipping (file statistics) and liquid clustering |
| Hybrid Columnar Compression | Parquet compression in Delta tables |
| Range, list and interval partitioning | Liquid clustering; partition only very large tables by date if at all |
| Parallel query | Spark and Photon, scaled by cluster or warehouse size |
| Result cache | Databricks SQL result and disk caching |
| RAC for availability | Managed, serverless compute with automatic recovery |
| Resource Manager plans | Separate SQL warehouses and job compute per workload |
| Materialized views and query rewrite | Materialized views in Databricks SQL, or Lakeflow Declarative Pipelines |
Heavily partitioned Oracle designs rarely translate well. Start with liquid clustering on the columns queries filter on, and measure.
3. Plan the data move
Size the history to move and the bandwidth available. Extract in parallel to cloud storage, write Delta tables in Unity Catalog, and switch to change data capture for the parallel run. For very large volumes, a physical transfer appliance can be faster than the network.
4. Convert, reconcile and cut over
Convert SQL and PL/SQL (see the Oracle to Databricks guide for empty strings, DATE, NUMBER and PL/SQL), benchmark the heaviest queries, then reconcile every table by domain before switching reports over.
5. Beat the refresh date
Work back from the support or refresh date, and make sure operational workloads have a destination in time. Otherwise the refresh happens anyway.
The short version
Separate warehouse from operational workloads, replace Smart Scan, HCC and partitioning with Delta data skipping, compression and liquid clustering, move history in parallel and sync with CDC, convert PL/SQL, benchmark, reconcile and empty the machine before the refresh.
Browse all migration guides, or estimate effort with the migration estimator.
Not sure where your own platform stands? Take the free 3-minute data platform scorecard, or see how we work on Databricks. Unfamiliar terms are explained in the data engineering glossary.