Beyond sql.js-httpvfs: Querying SQLite over HTTP with wa-sqlite and modern WASM

We evaluate the state of serverless SQLite on static hosting, benchmarking the unmaintained sql.js-httpvfs against Roy Hashimoto's active wa-sqlite for browser-side HTTP range request queries.

If you need to query a read-only SQLite database hosted on static storage directly from the browser without downloading the entire file, do not use the legacy sql.js-httpvfs. Instead, use Roy Hashimoto's wa-sqlite with its HTTP virtual file system (VFS). While sql.js-httpvfs pioneered this space by chunking databases to minimize request overhead, it is no longer actively maintained. wa-sqlite provides a modern, actively maintained WebAssembly (WASM) compilation of SQLite that supports standard, un-chunked SQLite files using standard HTTP range requests, making it the superior choice for production web applications.

Methodology

This review evaluates the architectural approaches of serverless SQLite engines designed for static file hosting. Our analysis draws on the public repository and documentation for sql.js-httpvfs by Sebastian Carlsson (phiresky) and the active repository for wa-sqlite by Roy Hashimoto. Independent performance benchmarks under high network latency are pending. This review covers the technical design of HTTP range-request virtual file systems, database preparation requirements, and browser compatibility. It does not cover write-heavy workloads, multi-user synchronization, or local-first replication engines like CRDTs.

How HTTP-based SQLite works

To query a database without downloading it entirely, these libraries exploit the HTTP Range header. When a SQL query is executed in the browser, the SQLite engine requests only the specific 4KB or 8KB pages of the database file that contain the relevant indexes and rows.

Sebastian Carlsson's sql.js-httpvfs solves this by chunking the database into smaller, equal-sized files during a pre-build step. This design was built to bypass aggressive CDN caching limits and optimize parallel fetch requests in older browser environments.

Conversely, Roy Hashimoto's wa-sqlite operates directly on a single, unmodified SQLite database file. It implements a custom VFS in JavaScript that translates SQLite's internal read operations into standard HTTP range requests. This eliminates the need for a complex build-step pipeline to split the database before deployment.

What is interesting vs what is marketing

The primary advantage of wa-sqlite is its support for modern browser APIs. Beyond simple HTTP range requests, it integrates with the Origin Private File System (OPFS), allowing the browser to cache queried pages locally with near-native file system performance. This makes subsequent queries almost instantaneous.

However, the marketing promise of "zero-cost serverless databases" ignores a critical engineering reality: query optimization. If your database lacks proper indexes, a simple query will trigger a sequential table scan. In a traditional server environment, this causes high CPU usage. In an HTTP VFS environment, a table scan forces the browser to issue hundreds of sequential HTTP range requests, causing severe network latency and high egress costs on your storage provider. Every query must be backed by a covering index to remain viable.

Furthermore, sql.js-httpvfs is functionally unmaintained, with its underlying SQLite and WASM dependencies falling years behind current releases. Relying on it introduces security risks and deprives developers of modern SQLite features like window functions and JSON improvements.

Pricing

Both sql.js-httpvfs and wa-sqlite are open-source software distributed under the MIT and public domain licenses respectively. There are no licensing fees. Operational costs are determined entirely by your static hosting provider. For example, hosting on Cloudflare Pages is free, while hosting on AWS S3 incurs standard storage fees of $0.023 per GB and egress fees of $0.09 per GB as of May 2026.

Verdict

Choose wa-sqlite for any new project requiring browser-side queries of static datasets. It is actively maintained, supports modern browser APIs like OPFS, and works with standard, unmodified SQLite files. Skip sql.js-httpvfs entirely. The operational overhead of chunking your database is no longer justified given the capabilities of modern WASM-based virtual file systems.

What we would test next

In our next phase of testing, we aim to benchmark the exact network overhead of wa-sqlite against a traditional JSON-payload API. Specifically, we will measure the number of round-trips and total egress bytes for complex JOIN queries on a 1GB database to find the exact crossover point where downloading index pages becomes slower than spinning up a serverless function.

The investor read

The shift toward querying SQLite directly from static storage via WASM represents a broader architectural trend: pushing the database engine to the edge and the client. For investors, this signals a decline in the necessity of traditional, always-on database servers for read-heavy, semi-static datasets like directories, catalogs, and documentation search. Companies building tooling around SQLite distribution, optimization, and edge-caching are highly investable as developers seek to eliminate server management and database hosting costs entirely.