Uber has moved roughly 90% of eligible Presto traffic onto Velox, Uber Engineering said, processing on the order of 100 petabytes a day with execution time down by more than half and CPU per query down by roughly two thirds.
That is the payoff, not the project.
Presto is the distributed SQL engine Uber uses for ad hoc queries and scheduled pipelines across dozens of clusters and thousands of hosts. Velox is a vectorized C++ execution engine that processes data in columnar batches built for SIMD instructions. The combination, called Prestissimo in open source, keeps the same SQL and clusters but swaps the Java JVM execution path for native code.
Uber made the bet because profiling showed more than 90% of Presto CPU went to one stage, scanning data, applying filters and projecting columns, according to the company. The JVM paid tax on every row through boxed objects, garbage collection and bytecode that rarely vectorizes. Early tests on scan-heavy queries showed up to 7x CPU savings, which justified the rebuild that started in December 2023.
The hard part was operational. Uber runs largely on Go, Python and Java, so C++ builds, debugging, CI and native dependencies were immature. JVM observability like heap dumps, GC logs and JMX did not transfer. Early native workers crashed and hit out-of-memory kills with little visibility.
Uber closed that gap before scaling traffic. The team added Prometheus metrics to Prestissimo through a sidecar using prometheus-cpp, scraped by Uber’s M3 metrics platform, which is Uber’s Prometheus-compatible backend for dashboards and alerting, according to the company. It adopted Velox memory arbitration in shared mode with the mmap allocator and tuned limits and pushback thresholds. Correctness was checked with Presto Verifier, which compares Velox and Java results, for the first 5% of queries.
Routing then changed in two phases. Phase 1 shadow-tested every query on Java and Velox and allowlisted only clean query fingerprints, reaching roughly 30% migration, according to the company. Phase 2 flipped to a blocklist of fingerprints known to crash Velox and let everything else through by default, which carried Uber to roughly 90% of eligible traffic.
Parquet compatibility decided whether that routing could hold. Parquet is the columnar file format that stores most of Uber’s lake. Uber found Velox misread nulls inside structs, arrays and maps and fixed backward compatibility for older files, reusing Java unit tests to generate files for Velox checks. The writer lagged further, with missing schema evolution, incomplete TIME and TIMESTAMP support, worse compression on numeric and MAP columns from a different encoding policy, and tables Spark SQL could not always read, according to the company. Fixes are being upstreamed, with Uber’s CLAC compression layer helping close the encoding gap.
Validation was stricter than a lab benchmark. On more than 40,000 queries across 1,000 query shapes, Velox delivered 3.73x better CPU time and 2.5x better elapsed time at matched capacity, according to the company. With 30% less capacity, Velox still beat full-capacity Java by 3.55x on CPU and 1.47x on elapsed time. A later four-day shadow test on 48-core machines colocated with Alluxio replayed live production timing into identical Java and Velox clusters using Uber’s Modulator traffic tool. Java sat pinned near 95% median CPU while Velox ran at 35% to 70%, Velox finished 22,374 queries to Java’s 21,003, success was 99.12% versus 92.43%, queue-full rejections hit about 4.4% of Java queries, and time-limit failures were 663 on Java against 7 on Velox. Headline result was 2.4x faster average execution and 3.06x lower CPU.
The same native push is spreading beyond Presto. For Spark workloads Uber adopted Apache Gluten with Velox to offload SQL operators to the vectorized engine, reporting roughly 3.5x faster queries and 3.4x lower CPU cost across migrated jobs. That context helps explain recent lab work on Spark writes, which tested a narrower write path rather than fleet query serving.
Watch the writer and the last 10%. Geometry functions alone consume about 15% of Presto CPU at Uber, and Velox geometry support is still being upstreamed with serialization in progress. Until Parquet write parity and those edge fingerprints land, Velox growth depends on blocklist maintenance rather than a finished migration.
