DuckDB in the Browser: Why We Chose WASM Over Server-Side SQL

When we started building Harbinger Explorer, we faced a fundamental architectural decision: where should SQL queries execute? The traditional answer is "on a server," but we chose a radically different path — running DuckDB entirely in the browser via WebAssembly.

The Server-Side SQL Problem

Most data tools follow the same pattern: upload data to a server, run queries there, send results back. This creates several issues:

• Infrastructure costs — You need servers running 24/7, even when nobody is querying
• Data privacy concerns — User data must leave the browser and live on your servers
• Latency — Every query requires a network round-trip
• Scaling complexity — More users means more server compute
• Cold starts — Serverless SQL engines need seconds to spin up

For an ad-hoc analytics tool where users explore small-to-medium datasets interactively, this overhead felt unnecessary.

Enter DuckDB WASM

DuckDB is an in-process analytical database — think "SQLite for analytics." Its WASM build runs directly in the browser, which gives us:

Zero Setup

No database server to configure, no connection strings, no drivers. The user opens Harbinger Explorer, and DuckDB is ready in under 2 seconds.

Data Stays Local

Files uploaded by the user never leave their browser. CSV, Parquet, and JSON files are parsed client-side and loaded directly into DuckDB's in-memory store. This is a privacy guarantee we can make with confidence.

Columnar Performance

DuckDB uses a columnar storage format internally, which means analytical queries (aggregations, filters, group-bys) run significantly faster than row-based alternatives. Even in WASM, performance is impressive.

Benchmarks: Browser SQL is Fast Enough

We tested typical analytical queries on datasets of varying sizes:

For interactive exploration, sub-second query times on million-row datasets feel instant. Users can iterate on their analysis without waiting.

The Trade-Offs

DuckDB WASM is not a silver bullet. Here are the honest limitations:

Memory Constraints

Browser tabs typically get 2-4 GB of memory. Datasets larger than ~1-2 GB will cause issues. For most ad-hoc analysis tasks, this is sufficient — but if you are working with 10 GB+ datasets, a server-side engine is more appropriate.

No Persistent Storage

DuckDB WASM runs in memory. When the user closes the tab, the data is gone (unless we persist to IndexedDB, which we do for frequently used tables). This is by design for a stateless exploration tool, but it means DuckDB WASM is not a replacement for a data warehouse.

Single-User

Each browser tab runs its own DuckDB instance. There is no shared state between users. For collaborative analytics, you need a centralized database.

When Server-Side is Better

We do not claim WASM SQL replaces server-side execution. Use server-side when:

• Datasets exceed 5-10 GB
• Multiple users need to query the same data simultaneously
• You need persistent, versioned storage
• Complex ETL pipelines require scheduled execution

Our Hybrid Approach

Harbinger Explorer uses DuckDB WASM as the primary query engine, but the AI agent runs on Cloud Run (server-side). This gives us the best of both worlds:

• Queries run in the browser — fast, private, zero cost
• AI reasoning runs on the server — access to large language models
• Crawling runs on the server — handles network requests and parsing

The user gets instant SQL without server costs, and the AI agent handles the heavy lifting of data discovery and schema mapping.

Conclusion

For interactive data exploration with small-to-medium datasets, DuckDB WASM is a game changer. It eliminates infrastructure, preserves privacy, and delivers performance that feels native. The trade-offs are real but manageable for the ad-hoc analytics use case.

Try it yourself at harbingerexplorer.com — upload a CSV, write a query, and experience browser-native SQL.