JSQLite is an open source project that translates the read side of the SQLite engine into TypeScript so SQLite databases can be queried directly in the browser, with no WebAssembly and no native code. It is in beta (v0.0.0-beta.2), only supports read queries and is released under the GPL v3. Its approach differs from the usual ways of bringing SQLite to the web, which compile the original C code to WebAssembly.

JSQLite vs SQLite in 30 seconds

JSQLite is a TypeScript translation of the SQLite 3.53.4 query engine that runs in the browser without WebAssembly or native code.
It is read-only: no writes, no transactions, no WAL recovery, and SQL coverage is partial.
It is still in beta, licensed under the GPL v3, tested only on Chromium and without published benchmarks.
For anything beyond static, read-only datasets, SQLite and its official WebAssembly build remain the safer and more complete choice.

The project is led by Salvador Fandiño together with the JSQLite contributors, and its GitHub repository already has more than 940 commits. The idea is easy to explain: a SQLite database file is published as a static file on a web server, the browser opens it over HTTP and runs the queries locally, in a dedicated worker, without sending SQL to any backend. The project website includes a playground with the Chinook sample database so it can be tried without installing anything.

What JSQLite does and what it does not

JSQLite is neither an automatic port nor a wrapper around the original library. According to its documentation, it is a fresh translation of SQLite’s C code into TypeScript, using the SQLite 3.53.4 source as its reference. The result is JavaScript that runs in the browser as ESM modules, with an API close to SQLite’s own: open, prepare, step, column, finalize and close.

On the SQL side it supports SELECT, joins, aggregates, subqueries, views, CTEs and window functions, with indexes and functions in the documented cases. It handles exact 64-bit integers as bigint, BLOBs as Uint8Array, UTF-8 and UTF-16 text, prepared statements and asynchronous execution with cancellation and resource limits. The project itself warns that not every combination or optimizer path is implemented, and that unsupported queries are meant to fail explicitly rather than return wrong results.

What it leaves out matters just as much to a sysadmin. There are no writes, no transactions and no WAL recovery, so the database has to be published as a clean, immutable snapshot, with journal or WAL changes already checkpointed. External extensions are not supported either. If the database is served from another origin, CORS has to be configured. Testing covers Chromium, and other browsers are not certified. It is not on npm yet: it is downloaded from the GitHub releases, and the full module tree has to be served.

JSQLite compared with SQLite and its browser builds

Comparing JSQLite with SQLite only makes sense with caveats, because they do not play in the same field. SQLite is a public domain C library embedded in operating systems, phones, browsers and applications, which reads and writes with ACID transactions, WAL mode and extensions. JSQLite takes only its query side and brings it to the browser in another language. Where it does compete is with the usual ways of running SQLite on the web, which rely on WebAssembly:

Feature	SQLite (C)	SQLite on WebAssembly (official and sql.js)	JSQLite
Where it runs	Native: server, desktop, mobile	Browser or Node.js via WebAssembly	Browser, in TypeScript/JavaScript
Read and write	Yes, with ACID transactions	Yes	Read-only
WAL and journal	Yes	Depends on the storage mode	No; needs a clean snapshot
SQL compatibility	Full	Full (same C code)	Partial, documented case by case
Extensions	Yes	Limited to those compiled in	No
License	Public domain	Public domain (official) and MIT (sql.js)	GPL v3 or later
Maturity	Over 25 years in production	Stable	Beta

The advantage JSQLite claims is not needing WebAssembly, which can help where it is restricted by security policies or where teams want to audit the code running in the browser in a more readable language. In exchange, it gives up writes and full compatibility, and it publishes no performance figures that would allow a comparison with the WebAssembly builds. The license matters too: the GPL v3 requires applications that distribute it to release their source code, which is not the case with SQLite or sql.js.

When it makes sense to use it

The use case the project has in mind is publishing a dataset as a static file and letting users query it from the browser: catalogues, open data, technical documentation or read-only dashboards, with no database server and no API in between. For a sysadmin that means fewer moving parts to maintain and secure, at the cost of serving the whole database as a public resource.

For any other scenario, SQLite or its official WebAssembly build, which offers writes and in-browser persistence, remains the sensible option. The JSQLite website itself asks users to review the beta scope and its limitations before choosing it for an application. For working with SQLite databases from the command line, tools such as SQLite-Utils or sqlit, a terminal UI for SQL queries are still useful, and for production environments with large datasets it is worth reviewing this practical guide to clustering, replication and sharding.

Frequently asked questions

What is JSQLite?

A TypeScript translation of the read side of the SQLite engine that lets SQLite databases be queried in the browser without WebAssembly or native code.

Can JSQLite write to the database?

No. It is read-only and supports neither transactions nor WAL recovery, so the database must be a clean, immutable snapshot.

How is it different from sql.js or SQLite on WebAssembly?

The WebAssembly builds compile SQLite’s original C code and offer reads, writes and full compatibility. JSQLite rewrites the query side in TypeScript, only reads and has partial SQL compatibility.