Sqlite3 WebAssembly

> These components were initially released for public beta with version 3.40 and will tentatively be made API-stable with the 3.41 release, pending community feedback.

But the most recent release of SQLite is 3.46.1 (from 2024-08-13)

Presumably they are now "API-stable" but the page hasn't been updated yet.

It would be great if the SQLite team published an official npm package bundling the WASM version, could be a neat distribution mechanism for them. (UPDATE: They do, see replies to this post.)

My favourite version of SQLite-in-WASM remains the Pyodide variant, which has been around since long before the official SQLite implementation. If you use Pyodide you get a WASM SQLite for free as part of the Python standard library - I use that for https://lite.datasette.io/ and you can also try it out on https://pyodide.org/en/stable/console.html

    import sqlite3
    print(sqlite3.connect(':memory:').execute(
        'select sqlite_version()'
    ).fetchall())

sqlite-wasm loads much faster than Pyodide, so if you don't need Python, then the former is a better choice.

    npm install @sqlite.org/sqlite-wasm

I think they've been doing that for a while, in JS script you can already do this:

    import sqlite3InitModule from "https://cdn.jsdelivr.net/npm/@sqlite.org/sqlite-wasm/sqlite-wasm/jswasm/sqlite3-bundler-friendly.mjs";

    const sqlite3 = await sqlite3InitModule({
        locateFile(file: string) {
            return "https://cdn.jsdelivr.net/npm/@sqlite.org/sqlite-wasm/sqlite-wasm/jswasm/sqlite3.wasm";
        },
    });

    // SQLite's C API
    const capi = sqlite3.capi;
    console.log("sqlite3 version", capi.sqlite3_libversion(), capi.sqlite3_sourceid());

    // OO API example below oo1 docs https://sqlite.org/wasm/doc/tip/api-oo1.md
    const oo = sqlite3.oo1;

    const db = new oo.DB();
    const createPersonTableSql = `
    CREATE TABLE IF NOT EXISTS person (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        name TEXT NOT NULL,
        age INTEGER NOT NULL
    );
    `;
    db.exec([createPersonTableSql]);

https://github.com/Ciantic/experimenting-sqlite-wasm/blob/ma...

Okay that's listed here: https://sqlite.org/wasm/doc/trunk/persistence.md

EDIT: Self answered.

With the help of Claude, though it incorrectly hallucinated some of the details despite me pasting in documentation: https://gist.github.com/simonw/677c3794051c4dfeac94e514a8e5b...

You may benefit from perusing the FAQ on that page.

Though it seems to be somewhat limited. I couldn't even check what version it has, since sqlite_version() was missing. Version in the repository [1] is 3.38.1, which is from quite a ways ago.

At the moment DuckDB web shell can't load SQLite extension, since that hasn't been released for yesterday's 1.1.2. Earlier version does work using recently updated WASM edition. That can be extended with spatial including GDAL, vector search etc [2]. Making your own "SQL web shell" wasn't too hard, though docs weren't quite complete enough for me.

[1] https://github.com/duckdb/sqlite_scanner/blob/main/src/sqlit... [2] https://github.com/duckdb/duckdb-wasm/releases/tag/v1.29.0

That's correct. i'll try my best to remember to update that reference the next time i'm back on the computer.

> It would be great if the SQLite team published an official npm package

Not a chance. We publish only vanilla JS and adamantly refuse to go down the rabit hole of supporting out-of-language tools (none of which any of our project members use). We support an "officially sanctioned" npm build, maintained by Thomas Steiner, but do not actively develop for any JS frameworks.

Direct support for any given framework (npm included) would give the impression that we endorse that framework, and endorsement of third-party projects is something we actively avoid.

A bit confused at this, NPM is just a package manager / distribution mechanism, not a framework. Totally fair if you don't want to publish for all the package managers, though for Javascript there's only a few that are relevant. NPM has been around for a decade.

It's an out-of-language packaging/distribution framework (and it's not the only one). It's not part of the JS standards.

My comments above have been edited to reframe our stance on npm and frameworks in general.

If you changed the word "framework" to "toolchain" in your post I think it would make a lot more sense to people.

Fair point but the edit window has passed ;). For the sake of clarity for those still following along: "framework," in the context of my above comments, includes any non-formally-standardized tools or APIs which are built atop the standardized core.

> I think they've been doing that for a while,

Kinda: <https://sqlite.org/wasm/doc/trunk/npm.md>

We in the sqlite project neither use nor require npm in any capacity whatsoever, so it would be kinda silly for us to attempt to support it. We instead leave that level of code/tools to folks who use and/or care about them.

There _is_ an "officially sanctioned/blessed" npm repo, and we actively support its maintainer (e.g. we participate the issue tracker and make patches in the core distribution where they're strictly needed), but we otherwise keep a "hands off" policy when it comes to non-standardized APIs and toolchains.

We _like_ to see people to plug the sources into their tools of choice, but we cannot feasibly take on the burden of doing that plugging-in for them, especially given how fluid the JavaScript ecosystem is when it comes to frameworks and tools.

Sidebar: we rely heavily on Emscripten because there is, for all practical purposes, it has no substitute, but we also actively go out of our way to ensure that the sources can be easily plugged in to an alternative should one ever appear.