DuckDB-Wasm is the WebAssembly build of DuckDB, an in-process SQL OLAP database management system, that runs analytical SQL queries entirely inside a web browser or a Node.js process — built for front-end developers and data engineers who want full OLAP query power on data that already sits on the client, without standing up a server.

What it is

DuckDB itself is an in-process SQL OLAP database management system: an analytical engine that runs inside the host process rather than as a separate server. DuckDB-Wasm is that same engine compiled to WebAssembly, so the database binary ships to the client and executes there. The port is currently based on DuckDB v1.5.4 and is tested on Chrome, Firefox, Safari and Node.js. It speaks Arrow fluently, reads Parquet, CSV and JSON files backed by filesystem APIs or HTTP requests, and lives in the analytics, browser, database, javascript, node, olap, sql, typescript and webassembly space. The project is written in C++ and released under the MIT licence, with a hosted shell at shell.duckdb.org and a visualiser at duckdb.org/visualizer.

The concrete problem it solves is the round trip. Querying a Parquet or CSV file that a browser already has access to normally means uploading it to a backend, running the query in a remote OLAP service, and streaming results back — or reimplementing a SQL engine in JavaScript. DuckDB-Wasm replaces both: it attaches database files and reads columnar files directly by URL, so the query engine travels to the data instead of the data travelling to the engine. Because DuckDB database files stay compatible, remote files can be mounted as simply as ATTACH 'https://blobs.duckdb.org/data/test.db'; FROM db.t;.

Key capabilities

• Runs DuckDB SQL inside the browser across Chrome, Firefox, Safari and Node.js, using the same query surface as the native engine.
• Reads Parquet, CSV and JSON over HTTP requests or filesystem APIs, and speaks Arrow fluently for zero-copy-shaped interchange with JavaScript.
• Attaches remote DuckDB database files directly by URL, with full read compatibility against files written by native DuckDB.
• Supports the extension model: INSTALL h3 FROM community;, INSTALL sqlite_scanner FROM 'https://extensions.duckdb.org';, then LOAD; install is lazy, deferring the fetch until the first LOAD extension_name;.
• Autoloads core extensions such as autocomplete, JSON, Parquet and ICU at runtime instead of bundling them, because the builds are optimised for download speed.
• Provides geospatial support through INSTALL spatial; LOAD spatial;, including functions such as ST_Point and ST_Distance in SQL.
• Offers LOAD httpfs to opt into the native-style HTTP path, re-implemented in JavaScript, with all requests upgraded to HTTPS and cross-origin access required on the resource.

Who uses it and how

• Analysts and developers exploring data interactively use the hosted shell at shell.duckdb.org or the visualiser at duckdb.org/visualizer as a serverless SQL workbench.
• Web application teams embed it in front-end apps so users can query their own files locally; the duckdb-wasm-examples repository collects working web-app examples, and third-party embeddings are catalogued by the DuckDB community.
• Node.js services and build pipelines run the same WebAssembly build where a native binary cannot be installed, covering batch or request-scoped analytics.
• Geospatial teams query station or point data straight from HTTP and S3-hosted Parquet files, computing distances in SQL without an ETL copy.
• Data platforms that publish Parquet or DuckDB files over HTTP let clients attach and query those files by URL, keeping the data resident on object storage.

Getting started

Install and API instructions live in the module documentation at shell.duckdb.org/docs/modules/index.html, alongside runnable examples in the duckdb-wasm-examples repository. The quickest way to evaluate it is the hosted shell at shell.duckdb.org or the visualiser at duckdb.org/visualizer.

How it compares

No comparable browser-embedded OLAP SQL engine is named in these facts, so DuckDB-Wasm stands alone in this registry. Its nearest reference point is native DuckDB, from which it differs in its default HTTP stack, runtime extension autoloading, sandboxing and single-threaded default, while keeping file-level and SQL compatibility.

When to use it — and when not to

Choose it when the data already lives in the browser, on the client filesystem, or at an HTTP or S3 URL, and when an in-client analytical engine beats a backend round trip. Avoid it for workloads that need out-of-core operation or broad filesystem access, since the WebAssembly build is sandboxed and supports less of both; native DuckDB is the better tool there. Also note the honest edges: the default mode is single-threaded and multithreading remains experimental, ICU autoloading does not work in all cases so an explicit LOAD icu; may be required, extension coverage is a growing subset rather than the whole catalogue, and the repository carries a substantial backlog of open issues.

--- Excplicitly load extensions
LOAD icu;

--- Or have them autoloaded when using relevant functions or settings
DESCRIBE FROM read_parquet('https://blobs.duckdb.org/stations.parquet');  -- (this autoloads JSON)

--- Or register extensions
INSTALL h3 FROM community;
INSTALL sqlite_scanner FROM 'https://extensions.duckdb.org';
INSTALL quack FROM 'https://community-extensions.duckdb.org';

--- And then load them
LOAD h3;
LOAD sqlite_scanner;
LOAD quack;

FROM duckdb_extensions() WHERE loaded;

git clone https://github.com/duckdb/duckdb-wasm.git
cd duckdb-wasm
git submodule init
git submodule update
make apply_patches
make serve