What happened
Uber’s November 10, 2026 engineering announcement describes moving Presto query execution from its Java Virtual Machine-based engine to Velox, an open-source, vectorized C++ execution engine originally built by Meta and open-sourced in 2022. The project began exploration in December 2023. The community calls the combination of Presto and Velox “Prestissimo.” Uber says the migration leaves the SQL and clusters the same for users while changing the execution engine beneath them.
The scale is substantial: Uber says its Presto fleet serves hundreds of thousands of queries daily across dozens of clusters and thousands of hosts, processing hundreds of petabytes of data. Velox now handles roughly 90% of eligible traffic, on the order of 100 petabytes a day. The company reports higher query success rates, average execution time down by more than half and CPU consumption per query down by roughly two-thirds compared with the legacy Java engine. In an early proof of concept focused on scan-heavy queries, Uber saw up to sevenfold savings in CPU time.
Uber describes two performance comparisons. In one, the team ran more than 40,000 queries covering over 1,000 query shapes. At matched capacity, Velox delivered 3.73 times better CPU time and 2.5 times better elapsed time. With Velox running at 70% of the capacity used by Java, it still achieved 3.55 times better CPU time and 1.47 times faster elapsed time than Java at full capacity. The announcement also describes a later Performance Improvement Factor study for a 48-core machine configuration colocated with Alluxio. That study used shadowed live production traffic in identically sized test clusters, rather than relying on synthetic tests.
The rollout prioritized operational safety. For the first phase, traffic grew from zero to about 30% through shadow runs: queries ran on both engines, results were compared, and only clean fingerprints were allowlisted for Velox. At larger scale, shadow-testing every fingerprint became impractical. Uber switched to a blocklist of fingerprints known to crash Velox, allowing other eligible queries through. The team also built Prometheus metrics export for Prestissimo into Uber’s M3 monitoring system, used Presto’s Verifier to compare results, and tuned Velox memory arbitration, allocation, limits and pushback thresholds. Parquet work included fixing incorrect reads involving nulls in complex types, compatibility with older files, writer gaps in schema evolution and time types, and interoperability issues with Spark SQL.
What the archive adds
New Runtime’s earlier coverage has connected query planning to inference scheduling: its September 27, 2026 note on Quail described turning AI-SQL requests into a schedulable batch workload. A November 6, 2026 note on Uber’s Spark work covered performance and cost gains from Apache Gluten and Velox. This is a new event in the same broader thread: Uber reports extending Velox’s role in production data execution, now across most eligible Presto traffic.
Trend signal
This supports agent economics moves to completed work only weakly: Uber’s measures are execution cost and speed for data queries, not agent task completion. The stronger editorial signal is that teams can justify an infrastructure change with production-shaped workloads and capacity comparisons, rather than treating model or engine choice as a headline metric. This does not yet fit a pattern New Runtime tracks.
Why now
Uber says it explored Velox from December 2023 and spent over two years building the operational foundation before reaching today’s traffic share. The announcement presents the current figures as the payoff from that staged effort, including a more rigorous later study using shadowed production traffic.
Why it matters
For teams operating large query platforms, this is evidence that a lower-level execution engine can change infrastructure economics without forcing users to rewrite SQL. The reported gains are large enough to make capacity planning part of the migration decision, not an afterthought: Uber says Velox at 70% capacity still outperformed Java at full capacity in its comparison.
The more reusable lesson is that performance alone was not the deployment criterion. Uber had to protect against silent wrong answers in Parquet reads, manage native memory failures, instrument a C++ process and decide which query fingerprints could safely move. A team considering a similar change should treat correctness equivalence, observability and compatibility as gates for rollout, then expand traffic according to evidence rather than a single benchmark.
Limits and uncertainty
These are Uber’s own results, and the announcement describes company-specific workloads, clusters and measurement setups. It does not establish that other Presto deployments would see the same gains, nor does the excerpted account make the precise savings independently reproducible. The article is marked incomplete at the available boundary, so this note does not assess any later findings or qualifications on the page. The figures also describe eligible traffic; the remaining traffic and the reasons it is not eligible are not fully characterized here.
Skill to build now
Before changing a production query engine, create a shadow-evaluation path that runs the same workload through old and new engines and compares results by query fingerprint. Start with a small allowlist of verified query shapes, instrument crashes and memory behavior, and retain a rollback route. Uber’s later move from allowlist to blocklist illustrates why the rollout model may need to change as verification costs grow.
Reader takeaway
A production engine migration can yield major cost and latency gains while preserving existing SQL, but the hard part is proving it safe at scale. Uber’s account makes correctness checks, native-process observability, memory discipline and staged routing part of the performance story—not cleanup after it.