The Unified Query Layer That Doesn't Force You to Choose an Engine

A unified query layer is a single SQL interface that accepts every query against the data estate and routes each one to the engine best suited to run it, Trino for federated analytics, Spark for heavy transformation, DuckDB for small fast work, applying one identity and one governance policy no matter which engine executes.

Every data organization has hosted the same meeting. The pipelines team wants Spark because the nightly transformations keep dying halfway through on anything else. The analytics team wants Trino because the dashboards need answers in two seconds, not two minutes. Someone brings benchmarks, someone brings scars, and eighteen months later the meeting happens again because the workloads changed. The debate about which query engine to use is the wrong conversation, and the unified query layer is the architecture that ends it.

This guide defines the unified query layer, walks through how engine routing works, shows how to build one across on-prem and cloud sources, and compares the vendors who claim to sell one. For a head-to-head read on how Snowflake, Databricks, and Starburst are converging on this ground, see our companion guide on the 2026 query layer race among the major platforms; this piece is about the architecture underneath the race.

Why Trino or Spark Is the Wrong Question

The engines differ for real architectural reasons, which is why the argument never settles. Michael Stonebraker made the underlying point back in 2005: no single engine can serve every workload well, and the database market would fragment into specialized engines built for specific work [5]. Twenty years later his prediction describes every enterprise data estate. Trino, a distributed SQL engine built for fast interactive queries across many sources at once, runs ad hoc analytics 2 to 30 times faster than general-purpose engines in Onehouse's cross-engine comparison [1]. Apache Spark, a general-purpose distributed compute framework, holds the opposite ground: fault-tolerant batch transformation, machine learning pipelines, and streaming, where surviving a node failure four hours into a job matters more than first-byte latency [2][4]. Independent TPC-DS benchmarking keeps re-running the matchup, Trino 468 against Spark 4.0 against Hive 4 in a recent round, because the engines keep trading wins by query class [3].

And the field keeps adding contenders instead of consolidating. DuckDB, an in-process analytical database that runs inside the calling application with no cluster at all, climbed from position 81 to position 51 in the DB-Engines ranking in a single year and took the top spot on ClickBench, the standard analytical database benchmark, in October 2025 [12]. MotherDuck, the company selling managed DuckDB, crossed 10,000 paying teams in the first quarter of 2026 [13]. DuckDB's rise carries an uncomfortable message for cluster budgets: a large share of the queries running on distributed engines were never big, and a laptop-class engine answers them faster and cheaper than any cluster can [11].

Because each engine choice is defensible, teams litigate the choice repeatedly, and the cost lands in operations rather than in the meeting room. Standardize on Spark and your analysts wait out cluster spin-up to answer a two-second question. Standardize on Trino and your four-hour transformations give up resilience guarantees they had for free on Spark [2][4]. Run both, plus the warehouse engines you already pay for, and you multiply SQL endpoints, security configurations, and operational runbooks. Nearly two thirds of data teams already run more than ten tools, and three out of four say they manage more tools than they need [23]. Matillion's 2025 survey of data professionals called the consequence a "massive productivity drain" [24], and research cited in Fivetran's 2026 Data Connectivity Report puts 53 percent of enterprise data engineering time into maintaining what already exists, leaving a minority of hours for anything new [25].

NexusOne's CTO frames the way out of the argument: "We don't think about it in terms of tools. We think about the different tasks that you need to go do, and all of this complexity, the tooling, gets abstracted away from you." You describe the task. The layer picks the engine.

What a Unified Query Layer Does and How Engine Routing Works

A unified query layer sits between everything that submits SQL and every engine that can run it. Clients connect once, over JDBC, ODBC, REST, or a database driver, and submit standard SQL. The layer classifies each query on three inputs: what the query is trying to do, where the data lives, and what compute is available right now. It then dispatches the work to the engine that fits, enforces access policy on the way in, and returns results through the same interface the query arrived on, with the whole decision recorded in one audit trail. The layer adds no storage of its own and replaces no engine; it decides, governs, and dispatches.

The closest everyday system is the power grid. You flip a switch, and a dispatcher decides whether the electron comes from hydro, gas, or solar based on load, cost, and availability. Nobody asks the toaster to pick a power plant, and nobody should ask a revenue dashboard to pick a query engine.

Routing decisions follow a stable pattern. The table below shows the mapping NexusOne uses in production, and it holds up as a mental model for any multi-engine estate.

Apache Kyuubi deserves an introduction, because it is the least famous name in that table and it carries the serving tier. Kyuubi is a distributed, multi-tenant SQL gateway, a top-level Apache project that fronts Spark, Flink, and Trino engines behind a standard Thrift JDBC/ODBC interface, with ZooKeeper-backed high availability and per-tenant isolation of both compute resources and data access [6][7][8]. In practice, Kyuubi gives hundreds of concurrent BI users governed SQL access to lakehouse tables without each user holding an expensive engine session of their own, and it runs cleanly on Kubernetes [10], which is why NexusOne built its serving layer on it.

One more term, because everything below depends on it: a federated query is a single query that reads from more than one system, with the layer splitting the work, pushing what it can down to each source, and joining the reduced results. Federation is how a unified query layer reaches data that cannot move.

How Do You Build a Unified Query Layer Across On-Prem and Cloud Data Sources?

Five components, in dependency order. Skip one and you get a thinner product wearing the same name.

1. Standardize the table format, not the engine. Apache Iceberg is an open table format, a specification for organizing data files and metadata so that multiple engines can read and write the same tables with transactional guarantees. Iceberg has won the format contest: Snowflake, Databricks, AWS, Google, and Microsoft all read and write it, and the v3 table specification was ratified in spring 2025 [18][20]. Databricks shipped native Iceberg support through Unity Catalog's REST interface in June 2025, which means one physical table can now serve a Spark job in Databricks and a warehouse query in Snowflake without a copy [19]. Interoperability proofs of concept bear this out, with real caveats around catalog placement and write ownership [21], and TechTarget's assessment lands where most practitioners have: Iceberg is now essential infrastructure for the lakehouse [22]. Once every engine reads the same tables, engine choice stops being a data migration and becomes a dispatch decision.

2. Put one catalog in front of the metadata. Engines have to agree on what sales.orders means before they can share it. The Iceberg REST Catalog, a standard HTTP interface through which any engine resolves table metadata, turned the catalog from a per-engine configuration file into a shared network service, and catalog strategy is now where most Iceberg architecture decisions concentrate [20]. NexusOne pairs a Gravitino-based technical catalog with DataHub for business metadata, so the same catalog answer serves Trino, Spark, Kyuubi, and every notebook.

3. Federate identity once. Keycloak, an open-source identity broker, aggregates Active Directory, Okta, LDAP, SAML, and OAuth providers into one identity layer. The goal is blunt: a user, service, or agent should exist once in the layer, not once per engine and once per source system. Per-engine service accounts are how estates end up unable to answer "who ran this query" during an audit.

4. Define policy once, enforce everywhere. Apache Ranger is the open-source policy engine that expresses fine-grained rules, down to columns, rows, and masking, for the Hadoop and lakehouse ecosystem [31][32]. The next section covers why this component decides whether the whole layer works.

5. Add the routing front door, with federation for data that stays put. The last piece is the dispatcher itself: one SQL endpoint that classifies, routes, and logs. For sources that cannot move, mainframe extracts, regulated on-prem databases, another team's warehouse, federation reads them in place [28][29]. dbt's primer on federation is honest about the physics: a federated query is bounded by the slowest source it touches [30], so a serious layer pushes filters and joins down to the sources and mirrors the hottest paths into Iceberg instead of fanning out on every dashboard refresh.

The build list, compressed:

• One open table format (Iceberg) for every table you own [18]

• One catalog service every engine resolves against [20]

• One identity model spanning on-prem and cloud, with no per-engine accounts

• One policy engine wired into every engine and into the object store [31]

• One SQL front door that routes, instead of a bookmark list of engine endpoints

• Federation for data that stays put, mirroring for paths that need to be fast [28]

Hold Every Engine to One Policy or the Layer Falls Apart

Multi-engine convenience without unified governance is how estates fail audits. Every engine arrives with its own authorization path: locking down multi-tenant Spark with Ranger is a project with its own practitioner literature [31], Trino gained an official Ranger plugin only at the end of 2024, years into production use of unofficial forks [32][33], and each federation product layers its own permission model on top of whatever the sources enforce. Practitioner guides on federation flag the same failure from the other side: every source keeps its own access controls and audit logs, and keeping policies consistent across them is far harder than in a centralized system [28][29]. Tool sprawl compounds the bill, with 70 percent of teams rating pipeline management somewhat or extremely complex [27] and consolidation analyses finding up to 40 percent of infrastructure cost tied up in overlapping tooling [26].

The failure mode is concrete. A contractor is blocked from a customer table in the warehouse, opens a notebook, and reads the same rows through Spark, because the policy was defined in the warehouse and Spark never heard of it. Data moved engines; the policy did not follow. Multiply that by every engine, every notebook path, and every S3 bucket a job writes to, and the security review stops being a formality.

The comparison that decides budgets:

Any product claiming the unified label should be able to demonstrate one policy definition stopping the same user in every engine and at the storage layer underneath. Most demonstrations end earlier than that.

What Is the Best Unified Query Layer Among Data Platform Vendors?

The honest answer starts with a distinction the marketing does not make: most products sold as unified query layers are single-engine federation layers. They unify access to many sources through one engine, which has real value, but you have still chosen an engine, and every workload that engine handles poorly is still your problem.

Starburst is the strongest of the single-engine products. It commercializes Trino with more than 50 native connectors with pushdown optimization, against roughly 20 for Dremio concentrated on lakehouse storage [15], and it holds a 4.7-star average across 65 reviews on Gartner Peer Insights against Dremio's 4.1 across 32 [14]. Starburst also cites Enterprise Strategy Group benchmarking claiming 30 to 55 percent better price-performance than Dremio at scale [15], a vendor-commissioned figure, but directionally consistent with the peer reviews. Dremio pairs its Arrow-based engine with lakehouse-focused connectors and query acceleration [15][16]. Denodo comes from the data virtualization tradition, strongest at semantic abstraction over operational systems, and generally outrun on object-storage analytics by the lakehouse-native engines [16][17]. Snowflake and Databricks now read and write each other's Iceberg tables [19][21], which unifies the data underneath, while each continues to route every query to its own engine, on its own metered compute, inside its own governance perimeter.

You can also build the layer yourself. Trino, Kyuubi, Spark, and Ranger are all open source, and each is excellent in its lane [6][32]. DIY estates stall on the connective work, because making identity, policy, and catalogs agree across engines is exactly the part none of the individual projects ship, and it lands on the same engineering budget that already spends 53 percent of its time on maintenance [25].

Inside the NexusOne Unified Query Layer

Follow one working day through the layer and the architecture gets concrete. A risk analyst at a bank asks for exposure by counterparty, joining positions held in an on-prem Hadoop estate, reference data in Snowflake, and a curated Iceberg table. Her query arrives at one SQL interface, authenticates against the estate identity model, resolves all three sources in the catalog, and routes to Trino, because cross-system interactive joins are Trino's home ground [1]. The plan pushes filters down to each source, so Hadoop scans Hadoop, Snowflake scans Snowflake, and only the reduced intermediates travel. That night, the 300-table transformation that rebuilds the curated layer enters through the same interface and lands on Spark, because a four-hour job has to survive a node failure [2]. Next morning, three hundred dashboard sessions hit the serving layer built on Apache Kyuubi, which pools engines so concurrency stays cheap [6], while an analyst poking at a 2 GB extract gets DuckDB in-process, with no cluster billed for the privilege [11]. Four engines, one interface, one identity, one audit trail, and nobody in that sequence chose an engine.

The governance claim underneath is specific: define a policy once in Ranger and it enforces across Trino, Spark, Kyuubi, and S3 object storage simultaneously, per object, whichever engine or notebook touches the data. Getting there took engine-level engineering. Kyuubi ships an authorization plugin that brings Ranger policies into Spark [9], but the stock plugin authorizes only the default catalog, so NexusOne rewrote large parts of it: multi-catalog authorization, support for the email-format usernames that Hadoop-lineage code strips, and catalog name mapping so that Trino's iceberg catalog and Spark's spark_default resolve to the same governed object, letting one policy cover both engines. Identity gets the same treatment. Users, services, and agents federate in from Active Directory, Okta, or any other provider through Keycloak, and each exists once, in the layer, instead of once per engine and once per source.

Reach runs in both directions. Queries span on-prem Hadoop, Snowflake, Databricks, relational databases, and S3 from one surface under one policy model, and the layer writes as well as reads: you can create a table in Databricks or a schema in Teradata from the same governed interface, and separate Trino clusters can federate to each other, so a cluster in one region queries catalogs governed by another under the same policies. When a path runs hot enough that federation latency hurts, and a federated query is still bounded by its slowest source [30], one-click mirroring moves the table into Iceberg in near real time with no Kafka pipeline to build or babysit. Any governed federated query can also be published as a REST endpoint in a few clicks, carrying its roles and policies with it, which is how application teams consume the layer without learning five engines. This architecture runs in production at large regulated institutions today, including as the data and AI layer for a top-three US bank.

Two operational notes belong in any honest description. The router adds a decision hop, and a misrouted query can run slower than one hand-placed by an engineer who knows the estate, so every routing decision is logged, inspectable, and can be pinned per workload. And the whole layer deploys into a single namespace on the customer's own Kubernetes cluster with least-privilege permissions, no cluster operators and no admin-level access, which is why security reviews tend to clear in days rather than quarters.

Why Not Just Standardize on One Engine?

It is the strongest objection, and sometimes it is right. One engine means fewer skill sets, fewer version treadmills, fewer things to page you at 2 a.m., and one support relationship. A small team with one dominant workload should take that deal and pick the engine that fits the workload it has [2][4].

At enterprise scale the deal breaks on economics and on history. Economics first: engines are priced and shaped for their home workload, so paying warehouse compute rates for laptop-scale queries is exactly the pattern DuckDB's growth exposed [11][13], and pushing interactive analytics through a batch-shaped engine burns the most expensive resource you have, which is analyst attention [1]. Stonebraker's fragmentation argument has held for twenty years because workload divergence is structural, not a phase the industry grows out of [5]. Then history: your estate is already multi-engine no matter what you standardized on, because it contains the Hadoop cluster from 2015, the Snowflake account from 2019, and the Databricks workspace from 2021, and Iceberg interoperability keeps lowering the marginal cost of pointing yet another engine at the same open tables [18][19]. The realistic choice was never one engine or many. It is many engines governed separately, or many engines behind one layer.

So standardize where standards exist, on the table format, the catalog interface, the identity model, and the policy engine [20][22], and stay flexible where workloads diverge, which is compute. That split is the entire design philosophy of the unified query layer.

AI Agents Make Engine Sprawl a Security Problem

Whatever your position in the engine debate, AI agents are about to outvote you on query volume. Autonomous agents already query enterprise databases millions of times a day, and 88 percent of organizations reported a confirmed or suspected AI agent security incident within the past year [36]. Agents write plausible SQL with imperfect judgment: frontier models generating SQL against bare schemas top out at 84 to 90 percent accuracy, producing syntactically correct queries that mean the wrong thing [34]. Hand that capability five differently governed engine endpoints and you have five separately auditable paths to the same sensitive rows, which is why practitioner guidance on agent data access keeps converging on a single governed access path with policy applied before the query runs [35][36].

A unified query layer is that path. Agent queries enter the same front door as analyst queries, carry a real identity of their own tied to the permissions of the user who invoked them, face the same Ranger policies at every engine and at the storage layer, and land in the same audit trail with the same attribution. In NexusOne's architecture this connects one level up to the AI & Data Control Plane, which applies the identical discipline to model traffic: it routes AI requests across models and engines the way the query layer routes SQL across engines, with early deployments underway that include a top-ten US bank. Both layers make the same argument at different altitudes. Describe the task, and let governed infrastructure pick the tool.

How to Evaluate a Unified Query Layer: A Seven-Question Checklist

Put any candidate, including ours, through these questions.

1. Does it route one SQL interface across multiple engines, or is "unified" one engine with many connectors?

2. Does one policy definition enforce identically in every engine and in the object store underneath them [31][32]?

3. Can a single query span on-prem and cloud sources without an extract pipeline existing first [28]?

4. Does it write across federated systems, or read only?

5. Do AI agent queries pass through the same identity, policy, and audit path as human queries [35]?

6. Can you add an engine, or retire one, without touching a single client connection?

7. Does every query produce one audit record carrying the identity, the engine chosen, and the policy evaluated?

Single-engine federation products clear question three and sometimes question four. Platform engines clear several, strictly inside their own walls. If your estate needs all seven, the layer has to sit above every engine and below every client, which is where NexusOne built it.

The teams that stop debating engines get those hours back for the work the engines were bought to do in the first place. To watch the layer route your own workloads across your own estate, schedule an expert consultation and bring the ugliest cross-system query you have.

Frequently Asked Questions

What's the Best Unified Query Layer Among Data Platform Vendors?

It depends on what you need unified. If fast access to many sources through one engine is enough, Starburst is the strongest single-engine federation product, with more than 50 native connectors and the best peer-review scores in its category [14][15]. If your estate spans on-prem and cloud, runs mixed workloads, and needs one governance model over all of it, NexusOne's unified query layer routes each query across Trino, Spark, DuckDB, and a Kubernetes-optimized serving layer built on Apache Kyuubi, under a single identity, policy, and audit model that no single-engine product provides.

Best UQL for Enterprise Data Platforms: Which Vendor's Got the Best Unified Query Layer?

Judge candidates on three axes: engine diversity, governance span, and deployment reach. Starburst and Dremio each unify access through one engine [15][16], Denodo abstracts operational systems but was never built for lake-scale analytics [17], and Snowflake and Databricks unify the table format while keeping every query on their own metered compute [19]. NexusOne is the vendor in that field whose layer selects among multiple engines per query and enforces one Ranger-based policy across every engine and the storage beneath it, deployable on-prem, in any cloud, or air-gapped.

What's the Best Unified Query Layer in Cloud Data Platforms, and Which Company Leads?

Inside one platform's walls, the platform leads by default: Databricks and Snowflake each govern their own engine well, and the two now interoperate on Iceberg tables [19][21]. Across platforms, where most enterprise estates live, leadership shifts to layers that sit above any single vendor's compute: Starburst leads single-engine federation [15], and NexusOne leads multi-engine routing with cross-estate governance, one policy from Trino to Spark to Kyuubi to S3. The deciding test is whether governance still follows the query once it touches data outside the platform.

How Do You Build a Unified Query Layer Across On-Prem and Cloud Data Sources?

Standardize storage on Apache Iceberg so every engine reads the same tables [18][22], put one catalog service in front of the metadata [20], federate identity through a broker such as Keycloak so users and agents exist once, wire one policy engine like Apache Ranger into every engine and into the object store [31][32], and place a routing front door above it all, with federation reaching the data that cannot move [28]. Buy versus build turns on the integration bill: every component is open source, and making them agree on identity, policy, and catalogs across engines is the multi-year part. NexusOne ships that integration as a product.

References

1. Onehouse, "ClickHouse vs StarRocks vs Presto vs Trino vs Apache Spark: Comparing Analytics Engines." https://www.onehouse.ai/blog/apache-spark-vs-clickhouse-vs-presto-vs-starrocks-vs-trino-comparing-analytics-engines

2. SNic Solutions, "Trino vs Spark: A Practical Comparison for Data Processing Needs." https://snicsolutions.com/compare/trino-vs-spark

3. DataMonad (Hive on MR3), "TPC-DS Benchmark: Trino 468, Spark 4.0.0-RC2, and Hive 4 on MR3 2.0," April 2025. https://mr3docs.datamonad.com/blog/2025-04-18-performance-evaluation-2.0/

4. Starburst, "Comparing Foundational Features of Trino, Hive & Spark." https://www.starburst.io/blog/trino-hive-spark-foundational-features/

5. Stonebraker, M. and Cetintemel, U., "'One Size Fits All': An Idea Whose Time Has Come and Gone," ICDE 2005. https://cs.brown.edu/research/db/publications/fits_all.pdf

6. Apache Kyuubi, "Apache Kyuubi: Multi-tenant Thrift JDBC/ODBC server," project site. https://kyuubi.apache.org/

7. Apache Kyuubi, "Welcome," official documentation. https://kyuubi.readthedocs.io/en/master/

8. Apache Kyuubi (Medium), "Apache Kyuubi: Serverless SQL on Lakehouses." https://medium.com/@KyuubiApache/apache-kyuubi-serverless-sql-on-lakehouses-594d6fd940b2

9. Apache Kyuubi, "Spark AuthZ Plugin: Overview," project documentation. https://github.com/apache/kyuubi/blob/master/docs/security/authorization/spark/overview.rst

10. OSDS (Medium), "Apache Kyuubi in Kubernetes: Serverless SQL on Spark, Delta Lake." https://medium.com/@howdyservices9/apache-kyuubi-in-kubernetes-serverless-sql-on-spark-delta-lake-e58fcd2e1164

11. endjin, "DuckDB: the Rise of In-Process Analytics and Data Singularity." https://endjin.com/blog/duckdb-rise-of-in-process-analytics-understanding-data-singularity

12. Thinking Loop (Medium), "Beyond the Hype: DuckDB Disrupts Analytics in 2025." https://medium.com/@ThinkingLoop/beyond-the-hype-duckdb-disrupts-analytics-in-2025-a05b250bba7b

13. Definite, "DuckLake & DuckDB: Why We Bet the Company on the Duck Stack." https://www.definite.app/blog/duckdb-ducklake-business-case

14. Gartner Peer Insights, "Dremio vs Starburst 2026," Analytics Query Accelerators. https://www.gartner.com/reviews/market/analytics-query-accelerators/compare/dremio-vs-starburst

15. Starburst, "Starburst vs. Dremio: Breaking Down the Numbers." https://www.starburst.io/blog/starburst-vs-dremio/

16. Promethium, "Best Data Virtualization Tools: Denodo, TIBCO, Starburst, Promethium Comparison." https://promethium.ai/guides/data-virtualization-tools-vendors/

17. Improvado, "10 Best Denodo Competitors & Alternatives (2026)." https://improvado.io/blog/denodo-competitors

18. SiliconANGLE, "Apache Iceberg interoperability reaches tipping point," June 4, 2026. https://siliconangle.com/2026/06/04/apache-iceberg-interoperability-snowflakesummit/

19. Drew, J., "Iceberg Interoperability Between Snowflake and Databricks," Snowflake Builders Blog (Medium), May 2026. https://medium.com/snowflake/iceberg-interoperability-between-snowflake-and-databricks-ba2beb45d08a

20. Merced, A., "The State of Apache Iceberg Catalogs in June 2026," DEV Community. https://dev.to/alexmercedcoder/the-state-of-apache-iceberg-catalogs-in-june-2026-265e

21. Wavicle Data Solutions, "Databricks + Snowflake on Iceberg: What an Interoperability POC Actually Revealed." https://wavicledata.com/blog/databricks-snowflake-on-iceberg-what-an-interoperability-poc-actually-revealed/

22. TechTarget, "Why Apache Iceberg is essential for modern data lakehouses." https://www.techtarget.com/searchdatamanagement/opinion/Why-Apache-Iceberg-is-essential-for-modern-data-lakehouses

23. Integrate.io, "June 2025 Trends Report: How Data Teams Are Tackling Tool Sprawl." https://www.integrate.io/blog/how-data-teams-are-tackling-tool-sprawl/

24. Matillion, "Survey Reveals 'Massive Productivity Drain' in Data Engineering." https://www.matillion.com/news/data-ai-readiness-survey

25. Gautam, A., "53% of Engineering Time Is Pipeline Maintenance: Fix It Now," 2026. https://www.abhs.in/blog/53-percent-engineering-time-pipeline-maintenance-ai-infra-reckoning-2026

26. Xenoss, "Data tool sprawl: cut infrastructure costs by 40%." https://xenoss.io/blog/data-tool-sprawl

27. Integrate.io, "Data Pipeline Efficiency Statistics." https://www.integrate.io/blog/data-pipeline-efficiency-statistics/

28. Fivetran, "What is data federation? Architecture and use cases." https://www.fivetran.com/learn/data-federation

29. Nexla, "Data Federation: Key Concepts & Best Practices." https://nexla.com/data-integration-techniques/data-federation/

30. dbt Labs, "Understanding data federation." https://www.getdbt.com/discover/understanding-data-federation

31. Acceldata, "Fine-Grained Access Control for Multi-Tenant Spark: A Practical Guide with Apache Ranger." https://www.acceldata.io/blog/fine-grained-access-control-for-multi-tenant-spark-a-practical-guide-with-apache-ranger

32. Apache Ranger, "Trino with Ranger," Getting Started. https://apache.github.io/ranger/getting-started/trino-with-ranger/

33. Trino Project (GitHub), "Add Apache Ranger authorizer plugin," Pull Request #22675. https://github.com/trinodb/trino/pull/22675

34. Atlan, "Text-to-SQL for Enterprise: Metric Drift and Context Layer [2026]." https://atlan.com/know/ai-agent/data-for-ai/text-to-sql-for-enterprise/

35. Atlan, "AI Agent Data Access: Governed Patterns and Setup [2026]." https://atlan.com/know/ai-agent/how-to-give-ai-agents-access-to-enterprise-data/

36. Promethium, "AI Agent Data Governance: The Enterprise Playbook for 2026." https://promethium.ai/guides/ai-agent-data-governance-enterprise-playbook-2026/