Start where the data is
DuckDB can query analytical files directly. For an exploratory task, this removes a separate server setup and import step.
The exercise below creates its own tiny Parquet file in your current working directory. Choose a scratch folder with no existing demo_orders.parquet file.
Create a sample file
Run these statements in the DuckDB CLI or a DuckDB SQL connection:
COPY (
SELECT *
FROM (VALUES
(1, 'north', 120),
(2, 'south', 80),
(3, 'north', 50)
) AS orders(id, region, total)
) TO 'demo_orders.parquet' (FORMAT PARQUET);
The file contains three orders. It is deliberately small enough to verify the result by hand.
Query the file
SELECT region, SUM(total) AS revenue
FROM read_parquet('demo_orders.parquet')
GROUP BY region
ORDER BY revenue DESC;
The expected totals are north = 170 and south = 80.
You can also inspect the shape before writing a query:
DESCRIBE SELECT *
FROM read_parquet('demo_orders.parquet');
Understand what makes the pattern useful
Parquet stores data in a columnar layout. Reading only the needed columns can reduce unnecessary work, and file statistics can help engines avoid reading some data for applicable filters.
The amount skipped depends on the file organization and query. A WHERE clause is not a guarantee that only a tiny part of every file will be read.
Know the boundary
An embedded analytical database is not the same operational model as a shared transactional database server. File access, concurrency, memory, and application lifecycle still need design.
Start with local exploration. When moving to shared object storage or production jobs, add explicit credentials, resource limits, failure handling, and a reproducible environment.
Next experiment
Add a second Parquet file with the same schema and query both using a matching path pattern. Then deliberately change a column type and inspect how the reader handles the mismatch.