gluesql VS absurd-sql

Have you looked into other pure-Rust databases as well, such as sled or GlueSQL which has an SQL interface on top of sled? I wonder how those would compare to Persy.

There's a Rust project that's an SQL engine on top of an arbitrary key-value store too, GlueSQL https://github.com/gluesql/gluesql (and it has a sled backend)

I'm really glad to share the release of GlueSQL v0.8

Not really, but I'm aware of absurd-sql. Note that this requires IndexedDB and thus a browser environment.

I don't need SQL capabilities, so I didn't look into those options (there's also absurd-sql, which ports sqlite to the browser on top of IndexedDB).

Ironically I was just about to drop in absurd-sql [1] to a project, which uses indexeddb to back SQLite. This seems better.

[1] https://github.com/jlongster/absurd-sql

There is also absurd-sql that is sqlite3 in wasm using IndexDB as storage and it’s faster than IndexDB itself

[1]: https://github.com/jlongster/absurd-sql

Offline data: running it in the browser for an offline cache, similar to sql.js or absurd-sql.

We are very close to having WASM SQLite with persistence in the web platform. Until now SQLite compiled to WASM was in memory and you had to write the whole database out as a binary array to save changes. There is absurd-sql (https://github.com/jlongster/absurd-sql), which builds a virtual file system on top of IndexedDB for sqlite, its incredible, but a bit of an ugly hack.

However, the new file-access apis (https://developer.mozilla.org/en-US/docs/Web/API/File_System...) that are landing in browsers will fix this. One of the things it does is enable very efficient block level read/write access to a privet sandboxed filesystem for the websites origin, perfect for persistent sqlite. There is more here: https://web.dev/file-system-access/#accessing-files-optimize...