dsq: SQL Queries Over JSON, CSV, and Parquet
dsq loads structured files (JSON, CSV, Parquet, Excel) into an embedded SQL engine and runs your query, so one tool covers many formats.
dsq detects the format from the extension, so you point it at a file and query. For an array-of-objects JSON, each object becomes a row and nested fields are reachable with a path.
What it does
dsq reads one or more data files, infers their format, loads them as tables (named {} for a single file or by position), and executes the SQL you pass. Nested JSON fields are accessed with a dotted path in the SELECT list. Output defaults to JSON.
Common usage
dsq users.json 'SELECT name, age FROM {} WHERE age > 30'
dsq report.csv 'SELECT COUNT(*) AS n FROM {}'
# pretty table output and nested field access
dsq --pretty events.json "SELECT \"user.id\", type FROM {}"Options
| Flag | What it does |
|---|---|
| --pretty | Print results as an aligned table |
| -s, --stdin <format> | Read from stdin with an explicit format |
| -c, --cache | Cache the loaded data between runs |
| --schema | Print the inferred schema instead of querying |
| {} | Table name that refers to the (single) input file |
In CI
dsq shines when the same query must run across formats: point it at a JSON API dump or a CSV export with identical SQL. Use dsq --schema file.json first to see how nested fields were flattened, then quote dotted column names like "user.id" in the query.
Common errors in CI
"no such column: ..." usually means a nested field needs quoting as "a.b", or the schema flattened it differently than expected (check --schema). "unable to detect content type" means the extension is missing or unknown; pass -s with the format when reading stdin. A malformed input yields a JSON/CSV parse error from the loader before the SQL runs.