DuckPad

Why I built it

The first hour with an unfamiliar dataset is usually not a warehouse problem. It is a schema, quality, dialect, and query-discovery problem. DuckPad explores how much of that investigation can happen locally in the browser before a production pipeline exists.

The design constraint is deliberate: large parsing and analytical work should not block the UI, and local inspection should not require uploading raw files to a remote service by default.

What I built

• A bilingual React landing page and standalone interactive workspace prototype.
• A documented worker boundary for DuckDB-Wasm initialization, file registration, SQL execution, CSV dialect sampling, schema inference, profiling, cancellation, and timeout handling.
• A proposed Arrow RecordBatch path back to a virtualized UI rather than rendering complete large tables on the main thread.
• Testing, security, observability, error-handling, benchmark, and architecture documentation intended to make engineering trade-offs inspectable rather than hidden behind a demo.

What it taught me

• Performance claims are only useful when the metric and environment are explicit: time to first preview, time to schema, query latency, peak memory, main-thread responsiveness, and export throughput are separate budgets.
• A local-first product still needs honest fallbacks. Browser memory, OPFS support, and cross-origin isolation define a real execution envelope.
• Architecture documentation is part of the product when the goal is to demonstrate engineering judgment: what is implemented, what is proposed, and what remains roadmap work must stay visibly separate.