Analytical databases running on local SSDs rarely face I/O bottlenecks because pushdown filters and partition pruning eliminate most scan overhead. Once you move that database to an EC2 instance querying Parquet files on Amazon S3, synchronous reads completely fail to saturate the available network bandwidth.
DuckDB tackled this in version 2.0 by restructuring its scan pipeline around asynchronous I/O. Instead of blocking worker threads on synchronous HTTP range requests, the engine decouples data reading from operator execution. Background threads issue pipelined asynchronous requests across row groups, buffering data ahead of the vectorized execution engine.
This pattern shifts analytical workloads from latency-bound stalls to pure throughput saturation. For remote data lakes, modern query engine speed depends far more on network request pipelining than raw SIMD compute kernels.
Optimizing query execution without fixing your storage access path is just optimizing idle wait cycles.







