Skip to main content

WASM and Spin Storage

3. Custom SQLite & Checkpoint Storage on WASM/Spin

The WASM Sandboxing & Native C Compilation Problem

When compiling standard Rust applications to the WebAssembly target wasm32-wasip2, you will quickly run into compile-time or runtime walls if you pull in traditional database engines like rusqlite or diesel. Why? Standard native driver crates:
  1. Rely on Native C libraries: They expect to link dynamically to a local system C-library (libsqlite3.so or libpq.dylib), which is impossible inside a sandboxed WebAssembly container.
  2. Require Raw POSIX Syscalls: Traditional native drivers spawn threads and perform raw, blocking socket connections or open custom files descriptors—operations strictly blocked by the standard WASI sandbox.

How We Solve This: Extensible Traits & Spin Host-Calls

To circumvent these limits, our framework provides clean, pluggable EventStore and CheckpointStore traits. In Fermyon Spin, the host runtime manages a native, high-performance SQLite database engine. WebAssembly components communicate with this host engine using highly optimized WASM host-calls defined via WIT. Spin’s host SDK exposes this capability via spin_sdk::sqlite::Connection. By creating a custom adapter inside src/store.rs, we can bridge Spin’s host-supplied SQLite connection to our framework’s traits. Let’s see how this is implemented: