SQLite DB in web browser, with WASM

sql-js/sql.js: A javascript library to run SQLite on the web. @GitHub

sql.js is a javascript SQL database. It allows you to create a relational database and query it entirely in the browser. You can try it in this online demo. It uses a virtual database file stored in memory, and thus doesn't persist the changes made to the database. However, it allows you to import any existing sqlite file, and to export the created database as a JavaScript typed array.

sql.js uses emscripten to compile SQLite to webassembly (or to javascript code for compatibility with older browsers). It includes contributed math and string extension functions.

SQLite can run completely inside a web browser. This is made possible by compiling SQLite's original C code into WebAssembly (Wasm), allowing it to execute locally on the client side with near-native performance. Major applications like Notion use this exact architecture to speed up their web apps. [1, 2, 3, 4]

Depending on your project's needs, you can implement browser-based SQLite in a few ways:

1. Official SQLite Wasm

The core SQLite team officially supports and maintains a WebAssembly and JavaScript release.

• It lets you load the SQLite library onto a web page using vanilla JavaScript.
• It interacts with modern storage APIs like the Origin Private File System (OPFS) to persist physical database files across sessions.
• Note: To leverage OPFS persistence, your web server must be configured to output strict security headers, specifically and . [1, 7, 8, 9]

2. Community Libraries

If you prefer alternative wrappers, community-maintained solutions are widely used:

• sql.js: A highly popular port that compiles SQLite to JavaScript/Wasm. By default, it operates completely in temporary RAM (in-memory). While your data disappears upon a page refresh, it allows you to easily import an existing database file via an array buffer or export your session data back into a static file.
• wa-sqlite: An alternative wrapper designed for flexible virtual file systems (VFS), allowing developers to map SQLite engines smoothly onto IndexedDB or OPFS backends. [7]

3. Execution via Web Workers

Because SQLite operations are synchronous by nature, running heavy queries directly on the main thread can cause the browser UI to freeze. Best practices dictate loading your Wasm module inside a Web Worker or SharedWorker. The main browser tab safely communicates with the background worker using asynchronous messaging. [7, 9, 15]

a local-first app that requires permanent persistence, or do you just need a temporary in-memory database for data processing? [16, 17, 18]

[1] https://sqlite.org/wasm/doc/trunk/demo-123.md

[2] https://www.sqliteforum.com/p/sqlite-in-webassembly-running-databases

[3] https://recca0120.github.io/en/2026/03/04/sql-js-browser-sqlite/

[4] https://www.reddit.com/r/programming/comments/1f325me/how_we_sped_up_notion_in_the_browser_with_wasm/

[5] https://deepakness.com/blog/sqlite3-wasm/

[6] https://sqlite.org/wasm

[7] https://powersync.com/blog/sqlite-persistence-on-the-web

[8] https://developer.chrome.com/blog/sqlite-wasm-in-the-browser-backed-by-the-origin-private-file-system

[9] https://www.youtube.com/watch?v=m4OcLeOuIaA

[10] https://dev.to/hexshift/using-sqlite-in-the-browser-with-webassembly-and-react-local-first-apps-with-no-backend-5183

[11] https://github.com/sql-js/sql.js/

[12] https://webreflection.medium.com/a-persistent-sqlite-for-the-web-90083827d1f8

[13] https://powersync.com/blog/sqlite-persistence-on-the-web

[14] https://observablehq.com/@asg017/introducing-sqlite-lines

[15] https://medium.com/better-dev-nextjs-react/building-offline-ready-apps-with-sqlite-in-the-browser-0d4a7a19b8a3

[16] https://www.xanthium.in/connect-read-write-update-delete-sqlite3-database-python-cross-platform-tutorial

[17] https://github.com/DallasHoff/sqlocal/issues/39

[18] https://forum.xojo.com/t/how-to-put-a-web-sqlite-database-on-the-client-side/50784