cargopete (May 19 2026 at 10:31): cargopete (May 19 2026 at 10:31):Hi all - working on a redb-backed host implementation of wasi:keyvalue for Wasmtime, as a step toward the Phase 2 portability criteria. The current wasmtime-wasi-keyvalue crate only has an in-memory backend; I've built a working implementation with full store + atomics + batch coverage backed by redb (pure Rust, embedded, no external service, 7 tests passing including persistence across sessions and bucket isolation).
Code: https://github.com/cargopete/wasmtime-wasi-keyvalue-redb
Before going further I wanted to check on preferred approach:
I know redb doesn't directly satisfy the portability criteria (which calls for Redis/DynamoDB), so happy to tackle a Redis backend next if that's more useful for advancing the proposal. Just wanted to validate the host trait approach first.
Till Schneidereit (May 19 2026 at 21:44):I think landing it as an optional dependency would be challenging, because that'd still require us to vet redb and whatever additional transitive dependencies that'd bring in. Because of that, an external crate might be better, or perhaps an implementation in terms of an http or socket API which can then run as an external process
cargopete (May 20 2026 at 07:14):Update: took pchickey's feedback on board - both backends are now standalone crates rather than in-tree:
- redb (embedded, no external services): https://github.com/cargopete/wasmtime-wasi-keyvalue-redb
- Redis (satisfies Phase 2 portability criteria): https://github.com/cargopete/wasmtime-wasi-keyvalue-redis
Both implement the full store + atomics + batch surface against wasi:keyvalue@0.2.0-draft2. Happy to discuss the approach or contribute further if there's a preferred path for standalone impls.
Last updated: Jun 01 2026 at 09:49 UTC