rusqlite VS wasi-libc

As far as I know, the only option for an embedded SQL database is SQLite. The most actively maintained one, for rust, seems to be rusqlite (https://github.com/rusqlite/rusqlite).

Yes, but it's readonly. Also they did not merge loadable extensions support, which I need - https://github.com/rusqlite/rusqlite/pull/910

rusqlite 0.27.0, which looks like it's still the latest version

SQLite is written in C, while workers is based on V8 isolates, so it mainly runs JavaScript. Fortunately, it also supports running WASM through initialising and calling WASM modules via JavaScript. Emscripten can be used to build WASM from C, but I'd rather use it through Rust (using rusqlite), so this is what I focus on right away. Workers can also be written entirely in Rust using worker-rs.

For the persistence layer I used Rusqlite and r2d2-sqlite for creating a connection pool.

There are feature flags in chrono that make possible to disable usage of time: https://github.com/rusqlite/rusqlite/pull/1031

I want to use arrays in sqlite but the documentations for rusqlite doesn't have examples of how to use the extra array feature. How do I store and search text arrays in rusqlite?

Since this is a learning project, its probably not a good idea to count on this being production ready. If you need SQLite in your project checkout rusqlite. And for cross compiling issues simply use its bundled feature, makes it a breeze.

Effective debugging results in effective programming; itk-wasm makes effective debugging of WebAssembly possible. In this tutorial, adapted from the itk-wasm documentation, we walk through how to debug a C++ data processing pipeline with the mature, native binary debugging tools that are comfortable for developers. This is a fully featured way to ensure the base correctness of a processing pipeline. Next, we will walk through an interactive debugging experience for WASI WebAssembly. With itk-wasm, we can debug the same source code in either context with an interactive debugger. We also have a convenvient way to pass data from our local filesystem into a WebAssembly (Wasm) processing pipeline.

Communication between the WASM module and the rest of the application needs to be done in very simple types (bytes, ints and floats). No complex types are supported yet. This is why most WASM compilers also provide some glue-code to map between complex types like strings or arrays. The Web Assembly System Interface (WAS) is an on-progress standard aimed to solve this last limitation; once it's mature it will allow easy interoperation with almost every environment. WASI is already available in some WSAM compilers and runtimes.

Turns out (as u/FiloSottile predicted) WASI is good enough for the demovfs; it took a couple of patches to wazero (all merged), but it works.

Also, WASI has extremely rudimentary emulated memory mapping support but I would hardly call it working. You can see the current implementation here, it is pretty short: https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/mman/mman.c

That's referring to its use in browsers. It doesn't have to be used in a browser. If you are using it in a browser, JavaScript is required to interact with the browser APIs - if you're just doing some compute-heavy work, you don't need to talk to JS.

I think this is where WASI is trying to fill the void.

WASI is a modular system interface for WebAssembly. We aim to create a system interface that will be a true companion to WebAssembly and last the test of time. This means upholding the key principles of WebAssembly — portability and security.

Therefore, the introduction of WASM was followed, a short while later, by WASI - the WebAssembly System Interface. WASI is a standard API to give WASM code the ability to do system-level I/O. This allows WASM code running in a WASI-compliant runtime to do a lot of what a native process can do through syscalls.