A unified query layer is a single SQL access surface that lets analysts, applications, and AI agents query data across lakes, warehouses, streaming sources, and legacy systems without moving or copying the data. NexusOne provides this capability as a composable, Kubernetes-native layer that federates across Snowflake, Databricks, S3 and Iceberg, Teradata, and on-prem estates under one identity and governance model.

This guide explains how NexusOne's unified query layer works, which source systems it reaches, and how it compares to Databricks Lakehouse Federation, Snowflake, Starburst, and Dremio. It is the capability-level companion to our vendor comparison, Query Layer 2026: Snowflake vs Databricks vs Starburst [1], which scores the incumbents against eight evaluation criteria. Read that guide for the market-wide framework, and this one to understand what NexusOne ships.

Why a Unified Query Layer Matters

A typical enterprise estate now spans a Snowflake warehouse, a Databricks lakehouse, Iceberg tables on S3, a Teradata appliance that refuses to die, Kafka streams, and often a Hadoop cluster mid-retirement. Each system has its own SQL dialect, its own accounts, and its own permission model. The standard workaround is copying: ETL pipelines stage data from each source into whichever platform the analytics team prefers, and every copy adds pipeline maintenance, redundant compute spend, and a window for the copies to drift apart [2].

A unified query layer for enterprise data platforms removes the copy step. The federated query layer, an engine that plans one query across multiple physically separate sources, pushes filters down to each system and joins the partial results in the middle, a pattern popularized by Presto at Meta and carried forward by Trino [33]. Analysts get a single SQL surface, platform teams retire pipelines instead of building more, and AI agents, which cannot wait weeks for a new pipeline, get governed access to the whole estate through one interface [3].

How NexusOne's Unified Query Layer Works

NexusOne builds its unified query layer from open engines and adds the cross-system integration those engines do not provide on their own. Trino handles federated SQL execution [4], Apache Kyuubi provides the multi-tenant SQL gateway [5], and Apache Spark covers heavy transformation work [6]. Apache Iceberg is the default table format [7], Apache Gravitino and DataHub form the catalog and metadata plane [8][9], and Apache Ranger with Keycloak enforce one security model across all of it [10][11]. The whole layer runs on Kubernetes, which means it deploys the same way on AWS, Azure, GCP, on-prem hardware, or an air-gapped cluster [12][16].

How Queries Are Routed

Every query enters through a single SQL endpoint. Apache Kyuubi, an open-source gateway that manages engine sessions on behalf of many users and tools, receives the query and routes it to the right engine for the workload: Trino for interactive and federated analytics, Spark for large batch transformations [5]. For federated reads, Trino applies predicate pushdown, the technique of sending filters into each source system so only relevant rows travel back, then executes cross-source joins inside its own workers [13].

The same routing discipline extends to AI query routing. Agents reach the estate through governed Data APIs and MCP endpoints (MCP, the Model Context Protocol, is an open standard that lets AI agents discover and call tools and data sources) rather than raw database connections, and NexusOne routes every agent query under the identity of the invoking user [14][16].

Source Compatibility

Through Trino's connector library and NexusOne's own integrations, the platform queries Snowflake, Databricks (both Delta Lake and Unity Catalog tables), Apache Iceberg tables on S3 or any S3-compatible object store, Amazon Redshift, Google BigQuery, Teradata, PostgreSQL, MySQL, SQL Server, MongoDB, Cassandra, Elasticsearch, and Kafka, among the 30-plus production connectors Trino maintains [4][15]. NexusOne adds sources the open-source engines do not cover, including EBCDIC parsers for mainframe extracts [16].

Federation is read-write. You can create a table in Databricks or a schema in Teradata from NexusOne, and write-back operations carry the same governance as reads [16].

Consistency, Identity, and Governance

This is where NexusOne differs most from a standalone engine: identity and policy travel with the query. Keycloak provides the single identity plane, and Ranger enforces one policy simultaneously across Trino, Spark, Kyuubi, and S3 object storage, down to individual objects [10][11][16]. NexusOne patches the engines so Trino's Iceberg catalog and Spark's default catalog resolve to the same namespace, which lets one policy govern both engines instead of two policies drifting apart [16]. And when a query federates out to Teradata or Databricks, NexusOne carries the user's identity and policies to the target, so you do not need separate accounts in every federated system [16].

On the lake side, Iceberg supplies ACID transaction guarantees, the property that a transaction either fully commits or fully rolls back, with readers never seeing a half-written state [7]. Every hop of every query, from the SQL gateway to the federated target, lands in one audit trail [16].

NexusOne does not publish synthetic federation benchmarks, but the deployment evidence is public: Wells Fargo connected 30 applications to the NexusOne cross-estate layer in under four weeks and eliminated more than $130M in Cloudera licensing and hardware costs, against a license bill that had run more than $30M a year [16]. The 5-5-5 deployment model (5 minutes to provision, 5 days to first workload, 5 weeks to production) has held across recent enterprise deployments [16].

Which Vendor Has the Best Unified Query Layer? NexusOne vs. Databricks, Snowflake, Starburst, and Dremio

The honest answer depends on where your data lives and how much of the surrounding stack you want to assemble yourself. The table summarizes the field, and the analysis below unpacks each row.

Databricks and Snowflake offer the strongest federation for teams already standardized on their platforms. Databricks Lakehouse Federation reaches Snowflake, BigQuery, Redshift, PostgreSQL, MySQL, SQL Server, and a growing list of sources from Databricks SQL [17][18], and the Tabular acquisition deepened its Iceberg commitment [19]. Snowflake reads and writes Iceberg tables and originated the Apache Polaris REST catalog, a catalog exposed over a standard HTTP API so any engine can find and use the same tables [20][21][22]. In both cases, federation runs outward from the platform, governance is strongest inside the platform's own catalog, and neither deploys on-prem or air-gapped.

Starburst is the strongest standalone federation engine, with 50-plus connectors and a 2026 positioning built around a unified context layer that adds business definitions on top of Trino [23][24][25]. What Starburst leaves to you is everything around the engine: identity, cross-system policy, orchestration, and agent access are separate integration projects. Dremio pairs Iceberg-native lakehouse access with Apache Arrow transport [26], and SAP announced in May 2026 that it will acquire Dremio to power SAP Business Data Cloud, with the deal expected to close in Q3 2026 [27][28][29]. If your estate is not SAP-centric, Dremio's roadmap now points somewhere you may not be going.

NexusOne occupies a different position: the unified query layer ships inside an integrated cross-estate layer, so the query engines, catalog, semantic context, identity, and governance arrive as one Kubernetes-native unit rather than as an engine plus 20 to 30 integration projects [16]. The market increasingly splits this category three ways: the semantic or metrics layer, the headless query engine, an engine consumed through APIs and SQL endpoints rather than a bundled UI, and the AI agent query layer [30][31]. NexusOne spans the last two and adds a cross-estate semantic layer on top, which is the combination agent workloads need: agents discover governed data products over MCP, query them through one SQL surface, and write results back across system boundaries under the invoking user's permissions [14][16].

Why Not Just Use Your Primary Platform's Federation?

If 80 percent of your workloads already live in Snowflake or Databricks and you face no sovereignty constraint, your platform's native federation is the path of least resistance, and we say exactly that in the companion comparison [1]. The calculus changes when the estate is genuinely mixed and staying that way, when regulation keeps data on-prem or air-gapped, or when AI agents need governed reach into systems the primary platform cannot see. Those are the situations a vendor-neutral data federation platform exists to serve, and they are the situations NexusOne was designed around [16].

When to Choose NexusOne's Unified Query Layer

Four situations account for most NexusOne unified query layer deployments.

• Mixed lake and warehouse estates. You run Snowflake and Databricks side by side, plus Iceberg on S3 and a legacy warehouse. One NexusOne query joins all of them, so mixed lake and warehouse queries become the core workload rather than an unsupported edge case [4][16].

• Vendor-neutral, cloud-agnostic query. Banks, insurers, and healthcare systems that cannot move regulated data into a SaaS platform run the same NexusOne layer on-prem, hybrid, or fully air-gapped, because everything deploys on Kubernetes [12][16].

• Lock-in reduction. Exit costs live in the storage format and the catalog, not the SQL dialect. NexusOne defaults to Iceberg and the open Gravitino catalog, so you can swap or add engines later without rewriting pipelines [7][8][34].

• AI agent workloads. Data products are exposed over MCP endpoints and annotated Data APIs, agents operate under the same role-based access control as human users, and write-back is governed and audited. SBFe runs 160 financial institutions through this one governed layer, supporting 166 audits a year [14][16].

Getting Started With NexusOne

The fastest way to evaluate fit is against your own estate rather than a demo dataset. NexusOne provisions in about 5 minutes, connects first sources within 5 days, and reaches production in 5 weeks, with Embedded Builders doing the integration work alongside your team [16]. Start with the platform overview, read the Hadoop modernization guide if you are coming off Cloudera [32], and book an expert consultation to walk through your source systems and governance requirements.

Frequently Asked Questions

What Is a Unified Query Layer?

A unified query layer is a software layer that provides a single SQL interface to query data stored across multiple systems, including data lakes, data warehouses, streaming platforms, and legacy databases, without requiring the data to be moved or replicated. It abstracts the storage and compute differences underneath, so users and AI agents get a consistent query experience regardless of where the data lives [2][4].

Which Vendor Has the Best Unified Query Layer for Enterprise Data Platforms?

It depends on your architecture. Databricks and Snowflake lead for teams already standardized on their platforms, and Starburst leads for broad, engine-only federation across many sources [17][20][23]. Dremio is strong for Iceberg-native lakehouse access, with a roadmap now tied to SAP [27]. NexusOne's unified query layer is built for enterprises that need composable, AI-ready query across mixed lake and warehouse estates without vendor lock-in, with identity and governance integrated rather than assembled [16].

How Does NexusOne's Unified Query Layer Work for Mixed Lake and Warehouse Setups?

NexusOne routes queries through Apache Kyuubi to Trino, which plans a single SQL statement across sources such as Snowflake, Databricks, Iceberg tables on S3, Teradata, and operational databases, pushing filters down to each source and joining results in the engine [4][5][13]. Identity and access policies travel with the query to every federated target, so one permission model governs the warehouse, the lake, and everything between them [16].

Is NexusOne's Unified Query Layer Compatible With Apache Iceberg and Open Table Formats?

Yes. Apache Iceberg is NexusOne's default table format, with read and write support through Trino, Spark, and Kyuubi, and Apache Gravitino provides an open REST catalog so other engines can reach the same tables [7][8]. Delta Lake tables remain queryable through the Databricks and Delta Lake connectors, which keeps mixed-format estates on the same SQL surface [15][17].

How Does NexusOne Compare to Databricks and Snowflake for Unified Query?

Databricks and Snowflake federate outward from their own platforms and are strongest when your data is already centralized in them [17][20]. NexusOne is vendor-neutral and treats every system, including Databricks and Snowflake, as a peer source under one identity, policy, and audit model, and it deploys on-prem, hybrid, and air-gapped where they do not [16]. If your estate is consolidated in one platform, use its native federation; if it is mixed and staying mixed, that is the situation NexusOne was built for.

References

1. NexusOne. "Query Layer 2026: Snowflake vs Databricks vs Starburst." https://www.nx1.io/blog/query-layer-2026-snowflake-databricks-starburst

2. Stonebraker, M., and Pavlo, A. "What Goes Around Comes Around… And Around…" ACM SIGMOD Record, 2024. https://db.cs.cmu.edu/papers/2024/whatgoesaround-sigmodrec2024.pdf

3. NexusOne. "AI-Ready Data Without Centralizing." https://www.nx1.io/blog/ai-ready-data-without-centralizing

4. Trino Software Foundation. "Trino Connectors." https://trino.io/docs/current/connector.html

5. Apache Kyuubi. "Kyuubi Documentation." Apache Software Foundation. https://kyuubi.apache.org/docs/latest/

6. Apache Spark. "Spark Documentation." Apache Software Foundation. https://spark.apache.org/docs/latest/

7. Apache Iceberg. "Iceberg Table Specification." Apache Software Foundation. https://iceberg.apache.org/spec/

8. Apache Gravitino. "Gravitino Documentation." Apache Software Foundation. https://gravitino.apache.org/docs/latest/

9. DataHub Project. "DataHub Documentation." https://docs.datahub.com/

10. Apache Ranger. "Apache Ranger Architecture." Apache Software Foundation. https://ranger.apache.org/

11. Keycloak. "Keycloak Documentation." https://www.keycloak.org/documentation

12. Trino Software Foundation. "Running Trino on Kubernetes." https://trino.io/docs/current/installation/kubernetes.html

13. Trino Software Foundation. "Dynamic Filtering in Trino." https://trino.io/docs/current/admin/dynamic-filtering.html

14. Model Context Protocol. "MCP Specification." https://modelcontextprotocol.io/specification

15. Trino Software Foundation. "Delta Lake Connector." https://trino.io/docs/current/connector/delta-lake.html

16. NexusOne. "Platform Overview." https://www.nx1.io/platform

17. Databricks. "Connect to External Databases and Catalogs (Lakehouse Federation)." Databricks Documentation. https://docs.databricks.com/aws/en/query-federation/

18. Databricks. "Announcing General Availability of Lakehouse Federation." Databricks Blog. https://www.databricks.com/blog/announcing-general-availability-lakehouse-federation

19. Databricks. "Databricks + Tabular: Unifying the Lakehouse." Databricks Blog, June 2024. https://www.databricks.com/blog/databricks-tabular

20. Snowflake. "Iceberg Tables in Snowflake." Snowflake Documentation. https://docs.snowflake.com/en/user-guide/tables-iceberg

21. Snowflake. "Snowflake Open-Sources Polaris Catalog." Snowflake Blog, 2024. https://www.snowflake.com/en/blog/introducing-polaris-catalog/

22. Apache Polaris. "Polaris Catalog Documentation." Apache Software Foundation. https://polaris.apache.org/

23. Starburst. "Enterprise Intelligence Platform." https://www.starburst.io/

24. Starburst. "Starburst Connectors." https://www.starburst.io/platform/connectors/

25. SiliconANGLE. "Starburst Bets on Semantic Context to Solve Enterprise AI Trust Problem." May 28, 2026. https://siliconangle.com/2026/05/28/starburst-bets-semantic-context-solve-enterprise-ai-trust-problem/

26. Dremio. "SQL Query Engine on Apache Arrow." https://www.dremio.com/platform/sql-query-engine/

27. SAP. "SAP to Acquire Dremio to Unify SAP and Non-SAP Data to Power Agentic AI." SAP News, May 4, 2026. https://news.sap.com/2026/05/sap-to-acquire-dremio-unify-sap-and-non-sap-data-power-agentic-ai/

28. Dremio. "SAP Intends to Acquire Dremio." Dremio Blog, May 2026. https://www.dremio.com/blog/sap-intends-to-acquire-dremio/

29. The Register. "SAP Dives Deeper Into Iceberg With Dremio Acquisition." May 5, 2026. https://www.theregister.com/software/2026/05/05/sap-dives-deeper-into-iceberg-with-dremio-acquisition/5226560

30. dbt Labs. "dbt Semantic Layer Documentation." https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl

31. Get Galaxy. "Best Data Virtualization and Federated Query Engines 2025." https://www.getgalaxy.io/learn/data-tools/best-data-virtualization-federated-query-engines-2025

32. NexusOne. "Hybrid Ready Data Platform: Legacy Hadoop Modernization Guide." https://www.nx1.io/blog/hybrid-ready-data-platform-legacy-hadoop-modernization-guide

33. Sun, Y., et al. "Presto: SQL on Everything." Meta Engineering Blog. https://engineering.fb.com/2019/05/29/data-infrastructure/presto/

34. Onehouse. "Open Table Formats Comparison: Iceberg, Hudi, Delta." https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison