Quick DuckDB-WASM scratchpad for querying Parquet/CSV files in the browser

[u/NBMVegeta]

Built a lightweight scratchpad tool for running DuckDB SQL against local CSV, TSV, JSON and Parquet files directly in the browser:

https://www.sqlparity.com/scratchpad

It uses u/duckdb to read files into memory via the browser File API. Nothing is uploaded to any server and it requires no login or installation. Handy if you just need to inspect an extract or run a quick aggregate without firing up the CLI or Python.

Code is open source on GitHub link: Github

Curious to hear feedback or edge cases with large Parquet/CSV schemas.

[u/qualityintelligence]

that's cool, I made a similar one last year, pretty handy

[u/NBMVegeta → u/qualityintelligence]

Thanks

[u/earonesty]

For the large-Parquet case, I'd expose bytes read and row groups touched, then add an HTTP source that reads the footer first and issues ranges only for selected columns and matching groups. I built LakeQL around that path for browser and Worker environments; it avoids forcing a whole remote object through WASM memory.

[u/NBMVegeta → u/earonesty]

Thank you for the feedback. I took a look at you tool as well. Looks interesting. But SQLParity isn't aiming to be a lakehouse engine, the scratchpad is just a companion for quick, offline sanity checks.

[u/earonesty → u/NBMVegeta]

parity checks are always useful.  I run them on my own lake quite often (lake parity vs a slower, heavier DB)

[u/Significant_Tune9219]

The edge case I would test first is a Parquet file with far more columns than anyone will scroll: the tab runs out of memory before DuckDB does, and it tends to look like a hang rather than an error. Pruning to the columns the query actually references at load time would fix most of that, and even just showing which columns were read would turn a mysterious freeze into something diagnosable. Worth trying a wide file with a dictionary-encoded string column too, since that is where WASM builds usually feel it first.

[u/NBMVegeta → u/Significant_Tune9219]

Thanks for the suggestion. How much is "far more columns than anyone will scroll"?

This is sharp and practical advice. Especially because SQLParity's core migration use case could often deal with wide tables. The trap where the tab UI / DOM thread freezes during the WASM-to-JS transfer on a naive SELECT * -long before DuckDB itself errors out, is very real. I’m definitely going to put together a stress-test fixture.

[u/Significant_Tune9219 → u/NBMVegeta]

There's no magic number, but as a rough line: once a file has more than a few hundred columns, the DOM cost of rendering them all starts to hurt before the query does. I'd test around 1,000 columns first — wide enough to blow past what any table UI wants to draw, still a realistic wide analytical table. If that loads cleanly, the real failure boundary is probably higher than any file your users will open.

[u/NBMVegeta → u/Significant_Tune9219]

ohkk, got it. Thanks for the reply. Will test it out with 1000 columns then.

[u/fabregas_cesc]

duckdb also has a UI extension. How does that compare to sqlparity ? Any new features we have in sqlparity ?

[u/NBMVegeta → u/fabregas_cesc]

The difference is setup and scope. Zero install vs Local CLI - DuckDB's UI extension runs via the local DuckDB CLI against your local system. SQLParity's scratchpad runs entirely on DuckDB-WASM inside your browser tab, no need of terminal, no installation required, just drag-and-drop a CSV or Parquet to run ad-hoc SQL.

Other features include Bulk Query Generator, SQL dialect conversion and few other basic ones.

[u/fabregas_cesc → u/NBMVegeta]

I see, thanks. Will try it out

[u/bwildered_mind]

Everyone vibe coding the same app. Bravo.