The lakehouse solved the storage problem. Now it’s exposing the query problem.
Organizations have spent the last decade moving data into open formats like Delta, reducing storage costs and eliminating lock-in. That strategy worked. Storage is no longer the dominant expense for most modern data platforms.
The challenge is that data volumes, query volumes, and AI-generated workloads continue to grow exponentially, while the economics of compute and data movement have barely changed. The result is a growing gap between the cost of storing data and the cost of querying it. And for many organizations, that gap is now measured in millions of dollars of cloud infrastructure spend.
The uncomfortable reality is that most organizations’ rising cloud bills aren’t from paying to store data anymore. They’re rising because they are repeatedly reading data they never use.
Every query starts with a simple question, but most engines answer it by scanning far more information than necessary. At small scale, the inefficiency is easy to ignore. At lakehouse scale, across billions of queries and increasingly autonomous AI workloads, it becomes one of the largest and fastest-growing costs in the data stack.
So here’s the question every data platform team should be asking:
Why does a simple query require reading 50 megabytes of data?
Pruning isn’t new. Pruning precisely is.
Every serious query engine prunes. Partitioning, predicate pushdown, column pruning. These are real, and they matter. But look at where they stop. They all operate at the file or row-group level. They throw away big blocks of data and then they read what’s left.
And what’s left still includes megabytes of irrelevant data needed to answer the query.
That’s the gap. You filtered down to the right row group, then read the entire row group to find a few rows inside it. At one query, it’s invisible. At enterprise lakehouse scale, across every query, every user, every agent, every day, it’s the difference between a query cost problem and a query cost solution.
What we’re announcing: StarTree queries Delta at the page level.
Today, StarTree reads your Delta tables directly. No copy, no conversion, no reverse ETL, and it prunes all the way down to the Parquet page.
Not the file. Not the row group. The page.
StarTree retrieves only the exact pages that contain your answer and leaves everything else unread on disk. Same query. Same Parquet files. Same Delta tables you already have. Dramatically less I/O, less CPU, and less local storage. If you are operating at scale, the cloud infrastructure cost savings are measured in tens of millions annually.
Also, answers come back in milliseconds, which is a nice thing to get for free when you were optimizing for cost.
This works against the Delta tables and Unity catalog you have right now.
Reading less data isn’t a theory. It’s already lowering cloud invoices at the biggest data driven companies.
The principle is simple, and our customers have been living it for years: when the engine reads less data, you don’t just get faster queries, you get materially lower infrastructure spend.
Uber is the clearest example. After moving their app-crash analytics off Elasticsearch onto Apache Pinot, the engine that powers StarTree, they cut infrastructure costs by 70 percent. CPU usage dropped 80 percent. Their data footprint shrank by 66 percent. Same questions, answered by reading and moving far less data.
Companies like Stripe, LinkedIn, DoorDash, and Walmart run on the same engine for the same reason: efficiency at scale is an architecture problem, and this architecture solves it.
None of those workloads needed to be on Delta for the math to hold. The principle doesn’t care about the table format. It cares about how much data the engine touches to answer a question. Point that same engine at your Delta tables, prune to Parquet’s page level, and the savings show up in the same place they always have: your cloud bill.
We measured it. StarTree scans far less Parquet.
We ran a three-way benchmark against Trino and ClickHouse on the same 12.2 billion rows of Parquet, and the data-read gap is stark.
To answer the same queries, StarTree read 5x less Parquet from S3: about 4.2 GB per worker, versus roughly 20 GB for both Trino and ClickHouse. On the most selective query, StarTree’s indexes narrowed 12.2 billion rows down to 25 matching records before reading a single column.
Reading one-fifth the data shows up everywhere it counts. StarTree ran at 7.1 percent CPU while Trino sat at 31 percent and ClickHouse at 45 percent. And cost per query came out 7.4x lower than Trino and 14.9x lower than ClickHouse, on identical hardware. See the full benchmark.
The best way to experience efficient query on the lakehouse is to see it for yourself. Book a demo and we’ll show you some examples and set you up with a trial for your own proof of concept.
