Starburst vs Dremio vs Databricks SQL: Choosing a Query Engine

Starburst, Dremio and Databricks SQL all execute SQL over lakehouse storage, and they are optimised for different things. Starburst is the federation engine: its strength is querying many heterogeneous systems in place. Dremio focuses on fast BI-layer analytics over an Iceberg-native lakehouse with aggressive acceleration. Databricks SQL is the analytical face of a broader data and ML platform, and is strongest where Spark-based processing is already central.

Disclosure: Yukon Labs implements Starburst. Where the other two are the better answer, this article says so — and for a substantial class of workloads they are.

The question that decides it

Not "which is fastest." The decisive question is what shape is your estate, and what are you allowed to do with it?

• If your data is already consolidated in one lakehouse and your processing is Spark-centric → Databricks.
• If your priority is fast dashboards over a lake with a modest number of sources → Dremio.
• If your data is spread across many heterogeneous systems you cannot consolidate → Starburst.
• If you must run entirely on-premise or air-gapped → this eliminates most of the field before performance enters the discussion.

That last point is worth taking seriously in this market. Databricks is fundamentally a cloud platform; there is no realistic air-gapped deployment. Dremio has self-hosted options but is increasingly cloud-oriented. Starburst Enterprise is designed to run in your own Kubernetes cluster and does so routinely. For a supervised Azerbaijani bank, that difference frequently ends the evaluation.

Federation

Starburst is built around this. Fifty-plus connectors covering relational databases, NoSQL stores, object storage, mainframe extracts and message systems, with a mature cost-based optimiser that pushes work down into each source, plus parallel JDBC extraction that removes the usual bottleneck when reading older relational systems. Joining an Oracle core banking table to an Iceberg table on object storage and a PostgreSQL operational database in one statement is the ordinary case, not a stretch. Independent comparisons in 2026 continue to put Starburst as the engine handling the widest range of source systems.

Dremio federates, but with a narrower connector set and a design centre that assumes most data is in the lake with a few external sources attached. It works; it is not the same breadth.

Databricks SQL federates through Lakehouse Federation, which has improved considerably, but the platform's assumption is that data comes into the lakehouse. Federation is a bridge during migration rather than the intended steady state.

If federation across a genuinely heterogeneous estate is your central requirement, Starburst is the strongest of the three and it is not particularly close.

Performance

Each is fast at what it is designed for, and comparing them on a single benchmark is misleading.

Databricks SQL (Photon engine) is excellent on large-scale analytical queries over Delta tables in its own environment. Where data is already in Delta on Databricks, it is very hard to beat.

Dremio achieves strong BI performance through an Apache Arrow-based engine with LLVM code generation and reflections — materialised, automatically maintained aggregations that queries transparently rewrite against. Dremio claims up to 20x acceleration on common patterns, and its Autonomous Reflections pre-compute aggregations without a human deciding which. For repeated dashboard queries this is genuinely effective and is Dremio's clearest differentiator.

Starburst performs well on federated and interactive queries, with caching and materialised views for repeated patterns. On a single-source query against data in its native optimised format, a specialised engine will usually win. On a query spanning four systems, the others are not competing — they cannot express it without a pipeline first.

The comparison that matters operationally is not engine-versus-engine on one query. It is total time to answer a new cross-system question, and that includes the pipeline that the non-federated options require.

Table format, catalog and lock-in

The file format question is largely settled — Iceberg is the neutral standard, and Databricks has proposed converging Delta's metadata structure with Iceberg v4. The live lock-in question in 2026 is the catalog, not the format.

Starburst is format-agnostic: Iceberg, Delta, Hudi, and plain Parquet or ORC, with the heaviest investment in Iceberg. Your data is in open files in your own object storage, and the engine is replaceable.

Dremio is Iceberg-native and co-created Apache Polaris, which graduated to a top-level Apache project in February 2026. Any engine speaking the Iceberg REST catalog protocol can read and write through the same catalog — an openly governed position.

Databricks originated Delta Lake and works best with it. Unity Catalog is a proprietary managed catalog; the open-source variant is Apache 2.0 licensed but is neither Polaris-based nor Iceberg-native. Interoperability has improved substantially, and migrating away remains achievable and non-trivial.

For organisations that have previously been through an expensive warehouse migration, engine and catalog replaceability is a recurring procurement requirement, and it favours Starburst and Dremio.

Cost model

Starburst licenses the cluster, with the compute running on your own infrastructure. Predictable, and it favours steady heavy usage. For on-premise deployments, the marginal cost of another query is your own hardware.

Dremio offers a free community edition and a commercial tier, generally lower total cost than the other two for a lake-centric workload.

Databricks SQL is consumption-priced. Flexible and genuinely efficient at variable load; it is also where organisations most often report cost surprises, because consumption pricing plus self-service analytics plus no query governance is a well-documented combination.

None of the three is cheap at enterprise scale. The models differ enough that the right comparison is a projection against your own expected query pattern, not a list-price comparison.

Ecosystem and skills

Databricks has the largest ecosystem by a wide margin — ML, streaming, notebooks, Unity Catalog governance, a large practitioner community and abundant training material. If your team is Spark-native, everything is familiar.

Starburst benefits from Trino's substantial open-source community, maintained by the Trino Software Foundation. Trino skills exist independently of the vendor, which is a real hiring advantage, and standard SQL means analysts need no retraining.

Dremio has the smallest community of the three, though its Polaris and Iceberg work has raised its profile considerably.

In Azerbaijan specifically, none of these skill pools is deep. SQL familiarity is the practical advantage, and it favours Starburst and Dremio over anything requiring Spark fluency.

Governance

Databricks Unity Catalog is a mature governance layer — lineage, access control, discovery — tightly integrated, and one of the platform's strongest features.

Starburst provides fine-grained row- and column-level access control applied uniformly across every federated source, including sources whose own security model cannot express such rules. For a bank, this is the standout capability: one policy layer over a heterogeneous estate, which is far easier to evidence to a supervisor than the same rules re-implemented six times.

Dremio offers reasonable access control, less comprehensive than either.

All three cover technical governance. None replaces a business catalog — definitions, ownership, business lineage — which remains a separate concern and is what OvalEdge addresses.

Which to choose

Databricks SQL if: you are already on Databricks, your processing is Spark-centric, ML and analytics share a platform, cloud deployment is acceptable, and you want one integrated environment. Do not choose it for federation, and do not choose it if you need on-premise.

Dremio if: your data is consolidated in a lake, your priority is fast BI dashboards, you want an Iceberg-native engine on an openly governed catalog, and cost matters more than federation breadth. Reflections are genuinely good at what they do.

Starburst if: your data is spread across systems you cannot or should not consolidate, you need on-premise or air-gapped deployment, you need consistent access control across heterogeneous sources, and you want the engine to remain replaceable.

For most banks and government institutions in Azerbaijan, the deployment constraint and the heterogeneous estate point to Starburst, which is why we implement it. For an organisation already committed to Databricks with data consolidated in Delta, moving to Starburst would be a downgrade, and we would tell them so.

A note on evaluating these

Three practical suggestions, learned from evaluations that went badly.

Test on your own worst query, not the vendor's benchmark. The query that spans four systems and takes a week to arrange today. That is the one whose behaviour you need to know.

Include the pipeline in the comparison. If option A runs a query in four seconds but requires a pipeline that takes three weeks to build, and option B runs it in forty seconds today, the honest measurement is time-to-answer.

Put security review in the proof of concept, not after it. For regulated institutions, the deployment and access-control questions are more likely to eliminate an option than performance is. Discovering that in month four is expensive.

Key points

• These optimise for different things. Federation breadth, BI acceleration and integrated platform depth are not the same product category.
• On-premise and air-gapped requirements eliminate most of the field before performance is discussed.
• Lock-in has moved from the file format to the catalog. Polaris versus Unity Catalog is the question worth asking in 2026.
• Compare total time to answer a new cross-system question, not single-query latency.
• Starburst's differentiator for regulated institutions is uniform row- and column-level access control across heterogeneous sources.
• None of the three replaces a business catalog.

Yukon Labs implements Starburst on-premise for regulated organisations in Azerbaijan and the region. Architectural background: data lakehouse architecture and Starburst and Trino in Azerbaijan.