Bringing Apache Pinot’s Query Efficiency to the Data Lake
The era of brute-force analytics is over. Bringing Apache Pinot’s query efficiency to the data lake means changing how analytical queries access data, not just where that data is stored.
Open table formats changed the lakehouse by making storage more flexible and open. But they did not fully fix query economics. For many teams, brute-force analytics is still the default: engines fetch far more data than the question actually requires.
Partition pruning, predicate pushdown, and metadata filtering help, but they often stop at the file or row-group level. What remains still includes unnecessary data access. At lakehouse scale, that extra I/O turns into higher CPU usage, more network movement, and inflated infrastructure spend.
This session looks at a different model: bringing Apache Pinot’s query efficiency to data lake workloads. Instead of reading broad chunks of data to answer selective questions, index-driven execution uses metadata and indexes to narrow data access before unnecessary Parquet data is read — including on open lakehouse tables such as Apache Iceberg and Delta Lake.
In this technical discussion, you’ll learn how to:
- Reduce unnecessary reads
See where lakehouse queries fetch more data than they need, and why that waste compounds as query volume grows. - Understand Pinot efficiency
Learn how Apache Pinot’s indexing and execution model narrows data access before unnecessary Parquet data is read. - Compare query cost drivers
Learn how to evaluate bytes fetched, CPU usage, latency, and cost per query to estimate the impact on your own lakehouse workloads.
You’ll also get a practical look at how to evaluate this model in a developer environment, using StarTree Tables Dev Edition to connect lakehouse tables, apply indexing, and inspect how query behavior changes when the engine fetches less data.
