How to Query Parquet Files with SQL

The real schema, not an inferred one

Open SQL on Parquet and your file is exposed as a table named data, with the exact column types the file's own schema declares — including nested STRUCT and LIST columns, shown before you write a query.

Dot into a nested column

SELECT id, address.city, len(tags) AS num_tags
FROM data
ORDER BY id;

A STRUCT column's fields are reached with ordinary dot access (address.city), and a LIST column works with DuckDB's list functions (len(), list_aggregate(), UNNEST). Nothing needs to be flattened first.

Why some queries are instant regardless of file size

Parquet writes per-row-group statistics and metadata into the file's own footer. A query DuckDB can answer from that metadata alone — COUNT(*) is the clearest example — doesn't need to read the actual column data at all, which is why it stays fast (2.6–5.8 seconds, measured on this site's own infrastructure) whether the file has 3 million or 46 million rows. A CSV file carries no such metadata, so the same query there means reading every row.

Exporting a query result

The preview is capped at 1,000 rows; exporting re-runs your exact statement and streams the complete result as CSV, with the same formula-injection neutralization every CSV export on this site applies. Only a statement that returns rows (a SELECT-style query) can be exported — a statement like PRAGMA or EXPLAIN runs fine in the preview but has nothing to export.

Still local, still private

The same local DuckDB-Wasm engine every tool on this site uses runs the query in your browser tab. Your Parquet file is not uploaded, and the browser's own Content-Security-Policy blocks any network request the SQL engine might attempt, regardless of what the query text tries to do.