Signed: GPT, Open Discovery research assistant
We accelerated a very specific operation:
Repeatedly calculate one customer’s results from a large shared dataset.
For example, imagine an analytics company serving thousands of healthcare providers. A dashboard for Provider 42 repeatedly asks:
“For Provider 42, in network 3, how many records are there, and what are the minimum, maximum, and total amounts?”
The slow version keeps looking through the large shared dataset, even though the request is only about Provider 42 in one network.
Our faster version makes a small table containing the original rows for Provider 42 in network 3. The next matching request reads that small table instead of searching everyone’s data.
Nothing is changed in the answer. We still run the filters and calculations. We only change where the database looks for the relevant rows.
If a request is not covered—for example, it asks for another network or many providers—we use the original full dataset instead.
On a deterministic 48-million-row synthetic Parquet lake:
- 19.90–22.60x faster in the first persistent-connection run;
- 20.07–23.13x faster in confirmation;
- 21.93–22.07x in a clean reproduction;
- exact outputs in all 14 correctness and fallback checks;
- 9/9 candidate wins for every tested provider;
- sidecar size: 1.06 MB versus 125.7 MB source;
- sidecar build time: about 0.22 seconds;
- build cost amortized after approximately 14–17 repeated queries.
These are local synthetic-fixture measurements. They are not a claim of a general DuckDB speedup, a production guarantee, or a measured customer saving.
The tested query restricted two columns:
provider_id = <value> AND network_id = 3WHERE provider_id = 42
AND network_id = 3The sidecar stores original rows, not a saved answer such as “the count is 8,060.” It is attached once to a long-lived DuckDB connection. The same SQL filters and aggregations are then evaluated against the smaller table.
Routing fails closed when the provider is uncovered, the query shape is unsupported, the source fingerprint is stale, or the sidecar receipt/hash is invalid. Those requests use the complete Parquet source.
The general pattern is:
large shared dataset + repeated exact customer/category filter
-> small original-row table for that slice
-> run the same query on the small table
-> use the full dataset when the slice is not safe
This can apply to SaaS dashboards, healthcare pricing, retail analytics, logistics, device monitoring, or any system where users repeatedly ask about small slices of a much larger dataset.
Requirements: Python 3 and a DuckDB CLI with Parquet support.
build_native_sidecar.py builds a native sidecar from a local dataset. The
full evaluator is intentionally tied to the research fixture schema so the
benchmark remains reproducible; adapt the selected key and query contract for
another workload.
python3 build_native_sidecar.py \
--duckdb duckdb \
--dataset ./parquet-drops \
--output-dir ./native-sidecar \
--providers 42 137 211 \
--network 3evaluate_native_sidecar.py compares the complete source against the attached
sidecar using interleaved repeated queries. It also checks unsupported and
stale cases fall back safely.
This experiment did not measure S3, concurrent tenants, incremental updates, real customer query distributions, joins, or a customer's cloud bill. The next step is a sanitized workload pilot with query logs, refresh cadence, and actual affected warehouse/ETL costs.