Your data lives in Databricks. Your pipelines are running, your Delta tables are populated, and your Gold layer looks clean. Now your BI team wants to connect Power BI and start building dashboards.
Here is where most teams hit a question they did not expect: should we query directly from Databricks SQL, or should we move data into a separate warehouse like Snowflake?
It sounds like a technical detail. It is actually one of the more expensive architecture decisions you will make. Pick the wrong answer and you pay for two systems, maintain two sets of data, and explain to stakeholders why the numbers from Databricks do not match the numbers from the warehouse.
Let me explain what Databricks SQL actually is, how the SQL warehouse works under the hood, how it compares to traditional warehouses like Snowflake and Redshift, and when you should use each one.
This article is part of the Modern Data Engineering: The Complete Guide series. The broader platform context is in What Is Databricks and Why Data Teams Use It. The architecture that Databricks SQL queries on top of is covered in Databricks for Data Engineering: Architecture, Components, and Best Practices.
What Databricks SQL Actually Is
Databricks SQL is the analytics and BI layer inside the Databricks platform. It lets SQL users, analysts, and BI tools run queries directly against Delta Lake tables without needing to know anything about Spark, notebooks, or clusters.
Think of it like a window into your lakehouse. Your data engineers built the pipeline. Your Delta tables are clean and governed by Unity Catalog. Databricks SQL lets your analytics team open that window and start querying, using the same SQL they already know.
You do not move data anywhere. You do not create a copy in a separate system. The same Gold layer tables that your pipelines produce are the ones your analysts query. One source of truth. Zero sync lag.
As the Databricks SQL documentation describes it: Databricks SQL is a set of services that let you run SQL and data manipulation language (DML) queries on data in your lakehouse, in addition to visualizations, dashboards, and alerts.
The compute resource that runs these queries is called a SQL warehouse. You create one, point your BI tool at it, and query your Delta tables.
What a SQL Warehouse Is and the Three Types You Can Create
A SQL warehouse is a compute endpoint. It is the engine that receives your SQL query, processes it against your Delta Lake data, and returns results.
Every SQL warehouse runs the Photon engine automatically. You do not configure or enable it. It is always on.
Databricks offers three warehouse types. Choosing the wrong one affects both cost and user experience in ways that are hard to fix after the fact.
| Warehouse Type | Startup Time | Auto-Scale | Performance Features | Best For |
|---|---|---|---|---|
| Serverless | 2 to 6 seconds | AI-powered (IWM) | Photon + Predictive IO + IWM | Most BI and analytics workloads |
| Pro | ~4 minutes | Reactive cluster-based | Photon + Predictive IO | Teams needing custom VPC or specific compliance controls |
| Classic | ~4 minutes | Reactive cluster-based | Photon only | Legacy configurations, entry-level performance |
As confirmed in the Databricks SQL warehouse types documentation: without support for Predictive IO or Intelligent Workload Management, a classic SQL warehouse provides only entry-level performance and less performance than a serverless or pro SQL warehouse.
The decision for almost every new team is simple: use serverless. The 2 to 6 second startup time is the most important number in that table.
Here is why it matters. A classic warehouse takes 4 minutes to start from cold. Your analyst opens a dashboard at 9am after it has been idle overnight. The dashboard query fires. The warehouse wakes up. The analyst stares at a loading screen for 4 minutes. They refresh. They wait. They start to distrust the tool.
A serverless warehouse starts in under 10 seconds. The analyst opens the dashboard. Results appear. They start working.
That user experience difference is the real reason Databricks recommends serverless for most workloads, not just the cost savings.
How the Photon Engine Works and When It Actually Helps
Photon is a vectorized query engine written in C++. It is built into every Databricks SQL warehouse. You do not install it, configure it, or turn it on. Every SQL query you run on a warehouse already uses it.
What makes Photon faster than standard Spark SQL execution: instead of processing one row at a time, Photon processes entire columns of data at once in batches. This is called columnar vectorized execution. Modern CPUs are very good at doing the same operation on large arrays of data simultaneously. Photon takes advantage of that.
As the Databricks cost optimization best practices documentation confirms: Photon is a high-performance Databricks-native vectorized query engine that speeds up SQL workloads and DataFrame API calls and reduces overall cost per workload. Databricks benchmarks its SQL offering at up to 12x better price/performance compared to traditional data warehouses.
The number sounds remarkable. Here is the honest part: Photon does not help every query.
As motherduck.com's 2026 guide to Databricks SQL alternatives notes directly: Databricks Photon can deliver up to 5x better price/performance for many workloads. Databricks also notes that Photon does not improve queries that normally run in under two seconds, where planning and scheduling overhead can dominate.
In plain terms: if your query already finishes in 1.5 seconds on a traditional warehouse, Photon will not make it faster. Photon helps large analytical queries. Multi-billion-row aggregations. Complex joins across wide tables. The workloads where the compute itself is the bottleneck, not the query planning.
For simple dashboard queries on pre-aggregated Gold tables, the difference between Databricks SQL and Snowflake in raw query time is often small.
Databricks SQL vs Snowflake vs Redshift vs BigQuery: The Real Comparison
This is the question that matters most for teams choosing their analytics layer. Here is what each platform actually does well and where each one falls short.
| Dimension | Databricks SQL | Snowflake | Amazon Redshift | Google BigQuery |
|---|---|---|---|---|
| Architecture | Lakehouse on open Delta/Iceberg | Cloud data warehouse, proprietary storage | Columnar MPP warehouse, AWS-native | Serverless warehouse, Google-native |
| Best query language | SQL + Python, Spark | SQL-first | SQL-first | SQL-first |
| ML and AI on same data | Yes, native | Limited Cortex AI | Redshift ML (SageMaker only) | BigQuery ML |
| Multi-cloud support | AWS, Azure, GCP | AWS, Azure, GCP | AWS only | GCP only |
| Cold start time | 2 to 6 sec (serverless) | Seconds to minutes | Minutes | Instant (serverless) |
| Data format | Open (Delta, Iceberg, Parquet) | Proprietary + Iceberg read | Proprietary + Spectrum | Proprietary |
| BI tool integration | Power BI, Tableau, Looker, Metabase | Power BI, Tableau, Looker | Power BI, Tableau, Looker | Looker, Looker Studio, others |
| Governance | Unity Catalog | Snowflake-native | AWS IAM + Lake Formation | Google IAM |
| When it wins | ML + analytics on same data, open format | SQL-only teams, data sharing, ease of use | AWS-locked teams, predictable workloads | Google Cloud teams, serverless SQL |
As eidosoft.co's February 2026 cloud data warehouse comparison notes: the cloud data warehouse market is projected to reach $183 billion by 2035. Platform selection in 2026 depends less on raw SQL performance and more on ecosystem fit, AI strategy, and how well a platform supports your data architecture going forward.
When Databricks SQL Wins
Your team runs both analytics and machine learning from the same data. Your data scientists train models on the Silver layer. Your analysts query the Gold layer. Both happen in the same platform with no data copies. No sync lag. No "which system has the right answer" conversation.
Your data volumes are large and growing. Photon's advantage grows with data size. Queries across tens of billions of rows on Databricks SQL cost less compute than the same queries on Snowflake SQL warehouses.
Your pipelines already run on Databricks. You built your Bronze-Silver-Gold stack. Adding a separate warehouse means maintaining a copy of the Gold layer in another system, building export pipelines, and explaining to stakeholders why two systems sometimes show different numbers.
When Snowflake Still Wins
Your team is SQL-only. No data scientists, no ML, no Python. Pure BI and reporting on structured data. Snowflake's interface is simpler, its SQL warehouse starts fast, and its management overhead is lower.
You need to share live data with external partners. Snowflake's data sharing features are the best in the market. A vendor or partner can query your live data without you exporting or copying anything.
You want zero infrastructure decisions. Snowflake's fully managed model removes every cluster sizing, warehouse type, and auto-termination decision from your team. That simplicity has real value for small data teams without dedicated platform engineers.
As flexera.com's June 2026 competitor analysis puts it directly: Snowflake is stronger for SQL-first BI workloads with near-zero management. The gap is narrowing, but Snowflake remains the better choice for teams whose primary workload is structured SQL analytics with no ML requirements.
Connecting Your BI Tools to Databricks SQL
Databricks SQL works with every major BI tool. Power BI, Tableau, Looker, Metabase, Sigma, and others connect via native connectors or the Databricks JDBC/ODBC driver.
The connection setup is the same for all of them:
- Create a SQL warehouse in Databricks
- Copy the server hostname and HTTP path from the warehouse connection details
- Paste those into your BI tool's Databricks connector
- Authenticate with a personal access token or OAuth
One setting that most teams miss: set auto-stop to 1 to 2 minutes for BI-facing serverless warehouses. The default auto-stop is 10 minutes. A dashboard that 20 people check every morning will keep the warehouse warm naturally. But a warehouse that gets one query at 9am and then sits idle until 3pm runs for 10 minutes of idle compute after every query. At scale, that idle time adds up to a significant monthly cost with no benefit.
As the Databricks SQL cost optimization documentation explains: serverless SQL warehouses scale down earlier than non-serverless warehouses, resulting in lower costs. The combination of fast startup and aggressive auto-stop makes serverless warehouses suitable for interactive use without the idle cost penalty.
The data governance for everything your BI tool queries runs through Unity Catalog automatically. An analyst who queries a Gold table only sees the rows and columns their role permits. Row-level security and column masking that your data team configured applies at query time, transparently, whether the query comes from Databricks SQL, Power BI, or Tableau. You configure the rule once. It applies everywhere.
How Unity Catalog enforces this governance layer across all consumers is covered in detail in Data Governance with Unity Catalog in Databricks.
The Two Mistakes Teams Make with Databricks SQL
Keeping a separate warehouse alongside Databricks. Teams that already have Snowflake or Redshift often continue paying for it after moving pipelines to Databricks. The logic is "we will migrate the BI layer later." Later takes two years. During those two years, the team runs export pipelines from Databricks Gold tables into the warehouse, maintains two sets of access policies, and investigates metric discrepancies between the two systems every month. If your Gold layer lives in Databricks, your BI layer should query it directly from Databricks SQL. The separate warehouse is costing you money and trust.
Using classic warehouses for production BI. Classic warehouses have a 4-minute cold start. No BI user will tolerate a 4-minute wait for a dashboard. Teams that launch classic warehouses and never auto-terminate them to avoid the startup delay end up with always-on compute billed 24 hours a day, 7 days a week, even when nobody is querying. Serverless warehouses with aggressive auto-stop eliminate both problems. They start fast enough that auto-termination after 1 minute of idle is practical.
What This Series Covers Next
- Medallion Architecture in Databricks covers how the Gold layer tables that Databricks SQL queries are designed, including how aggregations are structured for specific BI consumers and why over-materializing Gold tables creates the metric inconsistency problem.
- Data Governance with Unity Catalog in Databricks covers the full governance model for SQL access: row-level security, column masking, audit logging, and how access policies apply automatically to every BI tool query without any connector-level configuration.
- For teams building the business case for Databricks SQL over a standalone warehouse, How to Build a Business Case for Databricks Data Engineering covers the cost comparison methodology and the ROI arguments that resonate with finance teams.
