WhatTheDuck runs DuckDB entirely inside the browser tab

A SQL workbench with no server on the other end

WhatTheDuck is a web application built on DuckDB-WASM, and the whole architecture follows from that choice. Users upload CSV, Parquet, JSON, Excel, DuckDB or SQLite files, or import CSV, Parquet or JSON directly from a URL, the files are stored as tables, and SQL queries run against them. The engine is compiled to WebAssembly and runs in the page, so the data never has to be sent to a backend, and the README states plainly that your data is processed locally in your browser and will not be sent anywhere. That is the pitch for anyone who has been told to open a file in a hosted analytics tool and been unwilling to upload it. The application is a Quasar and Vue project, with the demo hosted on the project domain, and the repository is under MIT licence with the code on GitHub.

In memory by default, with an opt in for persistence

The data lifecycle is a deliberate decision rather than an accident. By default, the data lives in memory and is cleared on refresh, so a shared machine does not leave a trace of the file you were looking at. If you want tables to survive between sessions, there is a toggle in the Welcome dialog that opts in to persisting them in the browser's OPFS storage. That distinction matters when you judge the tool for a workflow: a one-off analysis of a spreadsheet needs nothing from persistent storage, while a multi-session analysis needs the toggle and a browser that permits the origin private file system. The application's own code is in src/, with the entry point index.html, a quasar.config.js, tailwind.config.js and postcss.config.js at the root, and the public/ directory holding the static assets.

Charts, exports and the .wtd session file

Query results are not just a grid. Results can be charted as bar, line, scatter or histogram, and downloaded as CSV, Parquet or JSON, and a whole session can be exported or imported as a .wtd workbook file. The .wtd format is the piece that turns the tool from a viewer into something you can hand to a colleague, since it carries the session rather than just the output. The charting stack is ECharts with the Vue wrapper, at version 6.1.0 of the core library and 8.1.0 of vue-echarts, and the file writing uses file-saver. The dependency list also includes ace-builds with vue3-ace-editor, which is a scriptable code editor, and that combination with the SQL workbench suggests the query editor is editable code rather than a fixed form. The Excel support comes from the xlsx package, pinned to a specific tarball URL at version 0.20.3 rather than a registry range.

Running it with Quasar, npm or Yarn

The build system is the Quasar CLI on Vite. Installing means cloning the repository, moving into the directory and installing dependencies, with either Yarn or npm offered:

yarn

npm install

Development mode runs with hot code reloading and error reporting:

quasar dev

That serves the app at http://localhost:9000, or another port if one is specified, and the production build is made with quasar build, which leaves the output in the dist directory. The manifest declares Node support as ^18, ^20, ^22 or ^24 with npm 6.13.4 or newer and Yarn 1.21.1 or newer, and it carries an override that pins esbuild to ^0.28.2 inside @quasar/app-vite, which is a hint that the default resolution had drifted. The package name field is duckdb and the version is 0.0.1 with the description A Quasar Project, which are placeholder values left in the manifest and worth knowing if you plan to fork and publish.

Docker runs the dev server, not a production image

The container setup is minimal and its purpose is worth stating precisely, because the compose file and the Dockerfile do not build a production deployment. The compose file defines a single service named quasar, built from the repository root with the Dockerfile, and it publishes port 9000 to the host. The Dockerfile starts from node:22-alpine, with a comment explaining the pin, since @quasar/app-vite v2 with Vite 6 needs Node 18 or newer and an unpinned node:alpine tag would eventually float past the range declared in the manifest engines field. It copies the package files, installs dependencies, installs the Quasar CLI globally, copies the rest of the source, and the default command is quasar dev. The comment above the exposed port even says 8080 while the value is 9000, a small inconsistency in a file nobody looks at closely. In other words, Docker here gives you a repeatable development environment, and the production artefact still comes from quasar build.

Against a hosted notebook and a local DuckDB binary

The realistic alternatives are a hosted notebook or BI service, and the DuckDB command line tool on your own machine. The hosted route is easier and more capable, and it is the one that wants your data uploaded, which is either fine or a blocker depending on the data. A local DuckDB binary is the closest comparison on capability, since the same SQL runs against the same formats, and it wins on large files because the browser holds everything in memory. What the browser version wins on is distribution: it needs no installation, it works on any machine with a browser, and a .wtd file can be sent to someone else to open. The honest limit of the approach is scale, because the file is parsed into browser memory and the tool is not designed for a dataset that does not fit.

Editorial conclusion

WhatTheDuck fits an analyst who wants to explore a CSV or Parquet file with SQL on a laptop with no server to stand up, and a team that cannot send raw data to a hosted service, since the DuckDB-WASM build runs entirely client side. It does not fit someone who expects a maintained product with a stable API, because the repository publishes no releases and the manifest still carries placeholder identity fields. Verify first that the file format you have is one of the accepted inputs, whether your browser allows the OPFS storage the persistence option relies on, and that a large file fits in memory, since the default mode keeps everything in memory and clears it on refresh.

Frequently asked questions

Official sources

1. incentius-foss/WhatTheDuck on GitHub
2. Issues
3. License: MIT
4. Project website
5. README