A person asks a question, reads the answer, and decides what to ask next. An AI agent runs that whole loop by itself, many times over.
Picture a fraud investigation agent. It pulls a flagged transaction from a payments database, checks the customer’s history in a data lake, looks up the open case in a ticketing system, and joins all three. Each step depends on the last, and each must respect what the person who started the task is allowed to see.
That puts the data layer inside the agent’s reasoning loop. It becomes a high-volume, governed, latency-sensitive workload. Two things have to be true. The agent must reach all the data it is allowed to use, wherever it lives. And the queries must run on compute that fits the job.
Agents need data that hasn’t been loaded
A converged platform bundles storage, compute, and governance into one vendor’s system, and you load your data in before you use it. That worked when analysts and dashboards asked predictable questions.
Agents break that pattern. The data they need is often in operational systems, other clouds, or on-premises, and it hasn’t been loaded anywhere. Copying it creates a second estate to secure, govern, and pay for. Access rules also have to apply to every query, for whoever is asking, not only to the data that made it into the platform.
When the engine that runs your queries lives inside someone else’s platform, its roadmap is theirs, and so is the decision about when your workloads change.
AI doesn’t make converged platforms disappear. It makes their constraints harder to accept.
The lesson from Presto
In 2012, a few of us at Facebook faced a related problem. Our warehouse couldn’t keep up with the data, and moving everything into a bigger centralized system wouldn’t fix it. So we built Presto to bring the query to the data. Presto became Trino, and that idea now powers analytics at some of the world’s largest companies.
The lesson came in three steps. First, federation: query data where it lives. Second, separating storage from compute, so each can change on its own. Third, and this is where AI pushes us, choosing the compute for each workload.
An open data layer should let an enterprise:
- Access data across warehouses, lakes, databases, and applications without centralizing it first.
- Apply consistent access controls, policies, and lineage to every query.
- Choose CPU or GPU compute for each workload without changing its data architecture.
Those choices should belong to the customer, not the platform.
Adding a GPU option: Starburst Torin
We continue to invest in Trino and in Starburst’s CPU engine. Starburst Torin adds a GPU option alongside them. Torin is a GPU-native, Trino-based engine for Starburst Enterprise, now in limited general availability.
Built on NVIDIA cuDF, Torin implements SQL operators directly for the GPU instead of adding GPU support on top of a CPU engine. NVIDIA engineers contributed cuDF expertise and guidance on optimizing for Blackwell GPUs. Torin runs alongside the CPU engine in the same query: supported operations run on the GPU, and anything else continues on the CPU. Teams keep their existing SQL and applications, and the data stays where it is.
In Starburst benchmarks derived from TPC-H, Torin ran queries 4.6x faster on average on NVIDIA Blackwell GPUs than our CPU engine. The same testing on Starburst Enterprise 483-e reaches up to 7x. On ClickBench, an NVIDIA L4 GPU instance delivered 3.4x the throughput of the CPU baseline at a similar hourly hardware cost.1
Those numbers measure analytical queries that scan and join a lot of data, not a full agent run. An agent’s total time also includes model inference, so the gain depends on how much of the task is spent waiting on queries. Results vary by workload and deployment.
The point is not that every query should run on a GPU, or that Torin runs on every chip. Torin runs on NVIDIA GPUs. The point is that a customer can choose CPU or NVIDIA GPU execution without moving data or rewriting SQL.
What the data layer has to do next
Agents need governed access to complete data, and they need enough query speed to finish their chains. Both are data layer problems. We built Trino on a simple idea: you shouldn’t have to move your data before you can ask questions of it. AI makes that principle matter more, and extends it to compute.
The organizations that pull ahead won’t simply be the ones with the most GPUs. They’ll be the ones whose data architecture can put those GPUs to work without starting over.
Join us on November 12 as we discuss this shift with NVIDIA. Register for the webinar.
Martin Traverso is a co-founder and the Chief Technology Officer of Starburst, and a co-creator of the open-source Presto and Trino distributed SQL engines. Starburst powers analytics and AI for enterprises in more than 60 countries, including four of the top five global banks.
1 The TPC-H and ClickBench results in this piece are from the testing published in the Starburst engineering blog. Up to 7x reflects the same TPC-H testing on the same NVIDIA Blackwell GPUs, run on Starburst Enterprise 483-e. Benchmarks ran on AWS in a development environment on single-node configurations, with warmup runs followed by measured runs. Speedups are geometric means across per-query ratios. TPC-H ran on g7e.4xlarge instances and ClickBench on g6.4xlarge instances, compared with an m8g.8xlarge CPU baseline. Cost figures are hardware only and exclude software licensing. Results vary by workload and deployment. Derived from TPC-H; not audited TPC results. Source: Starburst engineering blog.
