Skip to content
All services
Solution · BigQuery → Databricks

BigQuery to Databricks lakehouse, reconciled.

GoogleSQL to Databricks SQL, BigQuery ML to MLflow, slot reservations to SQL warehouses and job clusters, Unity Catalog adoption, Delta or Iceberg target storage. The codified rule library carries the dialect bulk; the architectural decisions land in the Discovery report.

The shape of this migration

BigQuery to Databricks is the second most-asked migration pair in 2026. The dialect overlap is high (75-80%); the architectural reframe is significant — slot economics to SQL-warehouse-plus-job-cluster economics, managed storage to Delta or Iceberg, BigQuery ML to MLflow tracked pipelines, IAM-based access to Unity Catalog. The Discovery report names every architectural decision per dataset with the trade-off shown.

What typically breaks first

  • BigQuery scripts and stored procedures. BEGIN...END scripting blocks become Databricks Python notebooks or SQL routines depending on logic shape. Multi-step transactional scripts sometimes move out of the warehouse to Airflow or Databricks Workflows.
  • BigQuery ML models. Linear / logistic regression, k-means, ARIMA — all translate to MLflow-tracked Spark ML or sklearn pipelines. BQML AutoML translates to Databricks AutoML. VECTOR_SEARCH translates to Databricks Vector Search.
  • UDF translation. BigQuery JavaScript UDFs and SQL UDFs translate to Databricks SQL UDFs or Python UDFs. The runtime semantics differ slightly — the validation harness catches edge cases.
  • Slot reservation → warehouse / cluster split. Workloads that ran cheaply on shared slots sometimes need their own SQL warehouse on Databricks. ETL workloads typically move to job clusters. The cost decision is named per workload in the Discovery report.
  • BI semantic layers. Looker LookML referencing BigQuery-specific functions, Tableau .twb files, Sigma worksheets — all need a regen pass. The wave plan keeps both warehouses live for 2-4 weeks while consumer owners sign off per-artifact.

What you receive at each wave

  • Written inventory: every table, view, UDF, stored proc, BQML model, dbt model, BI artifact, with the chosen translation path.
  • Translated DDL + DML from the codified rule library + bespoke handlers for the residual.
  • Unity Catalog setup document — workspace topology, catalog/schema/table organization, IAM-to-UC group mapping.
  • Delta-or-Iceberg call per dataset, with the consumer topology that drove the call.
  • Reconciliation report per wave: row-count parity, schema parity, float-tolerant checksums, query-result diffs on top-50 + top-20-by-cost queries.
  • Parallel-run window: 2-4 weeks of source + target both live with daily diff reports until consumer owners sign off per-dashboard.
  • Cutover document co-signed by your platform lead + ours.

Related reading on this pair

How to start

Most engagements start with a Cloud Cost X-Ray on the BigQuery side — currently free 90-min review (through Q3 2026), names the top-20 waste sources and feeds the SQL-warehouse-sizing model on the target. The free framing runs through Q3 2026; after that the same review reverts to a $100 5-day paid diagnostic, credited 100% to Execution if you sign within 60 days. For situations past the diagnostic phase, book a 30-minute call for direct Discovery scoping.

Questions buyers actually ask

Before you book a call.

Why move from BigQuery to Databricks? ▾
Common driver: ML and AI workload gravity. When the analytical workload is also feeding feature stores, model training pipelines, and inference endpoints, Databricks lakehouse + MLflow is a tighter fit than BigQuery + Vertex AI for a lot of teams. Secondary driver: lakehouse openness (Delta or Iceberg) vs BigQuery managed storage lock-in. We have also seen it driven by org structure — when a Databricks-first parent acquires a BigQuery shop. We will tell you when staying on BigQuery is the right call.
How parallel are GoogleSQL and Databricks SQL? ▾
About 75-80% parallel. The 20-25% rewrite work concentrates in BigQuery-specific functions (NEXT_TOKEN, ML.PREDICT, geospatial functions with edge cases), array/struct access syntax differences, scripting (BigQuery scripts → Databricks Python notebooks or SQL routines), and partition/cluster mapping (BigQuery PARTITION BY date → Delta partitioning + Z-ORDER). dbt models translate well; the BI layer typically needs more rework.
What about BigQuery ML — does it move? ▾
Mostly to MLflow + Databricks ML. Linear regression and classification models written in BigQuery ML translate to MLflow-tracked sklearn or Spark ML pipelines. AutoML training translates to Databricks AutoML. Deep-learning and embedding generation work that landed in BigQuery via VECTOR_SEARCH translates to Databricks Vector Search. The Discovery report enumerates every BQML model with the chosen rewrite path.
Slot reservations to SQL warehouses + clusters — how does the cost model change? ▾
Different shape. BigQuery slot economics buys autoscaling slots against a reservation. Databricks SQL warehouses are sized fixed (or autoscaling between a min and max) with auto-suspend; classic clusters for ETL workloads run separately. The cost-economic decision is which workloads need a SQL warehouse, which run as job clusters, and what sizes / auto-suspend windows fit. We typically run X-Ray-style telemetry analysis on the BigQuery side first to feed this model.
Unity Catalog — adopt it during the migration, or stay on Hive metastore? ▾
Adopt it. Unity Catalog is the right call for any new Databricks estate in 2026 — it carries the fine-grained access control, lineage, and audit logging that the hive metastore does not. Migration from hive to Unity Catalog mid-flight is more painful than landing on Unity Catalog from day one. The Discovery scope includes the Unity Catalog setup as a prerequisite.
Delta or Iceberg for the target storage? ▾
Delta as default; Iceberg as exception. Delta is the native Databricks format with the best feature coverage (auto-compaction, predictive optimization, deletion vectors). Iceberg is the choice when the same data needs to be queried by Trino, Spark outside Databricks, or other Iceberg-native engines. The Discovery report makes the call per dataset; mixed estates are common.