wasmtime / PR #13410 wasi-keyvalue: add optional redb per... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #13410 wasi-keyvalue: add optional redb per...

Wasmtime GitHub notifications bot (May 19 2026 at 15:35):

cargopete opened PR #13410 from cargopete:feat/wasi-keyvalue-redb-backend to bytecodealliance:main:

Summary

Adds a persistent redb-backed storage backend to wasmtime-wasi-keyvalue, behind an optional redb Cargo feature. The existing in-memory backend is completely unchanged.

Related Zulip discussion: https://bytecodealliance.zulipchat.com/#narrow/channel/441851-wasi/topic/wasi-keyvalue.20redb.20backend.20.28approach.20question.29

Standalone reference implementation: https://github.com/cargopete/wasmtime-wasi-keyvalue-redb

Design

New redb feature gate — zero cost when not enabled

Bucket becomes an enum: InMemory(HashMap<...>) | Redb(String)

WasiKeyValueCtxBuilder::redb_file(path) configures the database

Identifiers: "redb" → default bucket, "redb:<name>" → named bucket

All buckets share one database file; keys encoded as {bucket}\0{key}

Full store + atomics + batch interface coverage

Usage
let ctx = WasiKeyValueCtxBuilder::new()
    .redb_file("/var/lib/my-component/kv.redb")?
    .build();
Then open("redb") or open("redb:mybucket") from the component.

Notes

Opening this as a draft since I've just posted in #wasi on Zulip asking whether the preferred approach is an in-crate feature (this PR) or a separate published crate. Happy to go either direction — wanted to show concrete code either way.

I'm also aware redb doesn't satisfy the Phase 2 portability criteria directly (those require Redis/DynamoDB etc.). A Redis backend is next on my list — just wanted to validate the host trait shape first with a dependency-free embedded store.

Wasmtime GitHub notifications bot (May 19 2026 at 15:41):

cargopete updated PR #13410.

Wasmtime GitHub notifications bot (May 19 2026 at 15:42):

cargopete edited PR #13410:

Summary

Adds a persistent redb-backed storage backend to \`wasmtime-wasi-keyvalue\`, behind an optional \`redb\` Cargo feature. The existing in-memory backend is completely unchanged.

Related discussion: posted in the \`#wasi\` channel on the Bytecode Alliance Zulip (bytecodealliance.zulipchat.com) — topic: wasi-keyvalue redb backend (approach question).

Standalone reference implementation: https://github.com/cargopete/wasmtime-wasi-keyvalue-redb

Design

New \`redb\` feature gate — zero cost when not enabled

\`Bucket\` becomes an enum: \`InMemory(HashMap<...>)\` | \`Redb(String)\`

\`WasiKeyValueCtxBuilder::redb_file(path)\` configures the database

Identifiers: \`"redb"\` → default bucket, \`"redb:<name>"\` → named bucket

All buckets share one database file; keys encoded as \`{bucket}\0{key}\`

Full \`store\` + \`atomics\` + \`batch\` interface coverage

Usage

\`\`\`rust
let ctx = WasiKeyValueCtxBuilder::new()
.redb_file("/var/lib/my-component/kv.redb")?
.build();
\`\`\`

Then \`open("redb")\` or \`open("redb:mybucket")\` from the component.

Notes

Opening this as a draft since I've posted in \`#wasi\` on Zulip asking whether the preferred approach is an in-crate feature (this PR) or a separate published crate. Happy to go either direction — wanted to show concrete code either way.

I'm also aware redb doesn't satisfy the Phase 2 portability criteria directly (those require Redis/DynamoDB etc.). A Redis backend is next on my list — just wanted to validate the host trait shape first with a dependency-free embedded store.

Wasmtime GitHub notifications bot (May 19 2026 at 15:45):

cargopete commented on PR #13410:

One more CI note: cargo vet is flagging redb 4.1.0 as unvetted (no existing audit in any of wasmtime's trusted sources — Embark, Google, Mozilla, Spin). A cargo vet certify redb 4.1.0 safe-to-deploy audit would be needed before this could merge, which is ~29k lines of redb source.

This feels like relevant signal for the architecture question I raised on Zulip: if the backend lives in a separate published crate (as in the standalone repo), wasmtime itself never takes on the redb audit burden — only users who explicitly depend on the external crate do. Happy to keep this as an in-tree feature if that's preferred, but wanted to flag the vet cost explicitly.

Wasmtime GitHub notifications bot (May 19 2026 at 15:47):

cargopete updated PR #13410.

Wasmtime GitHub notifications bot (May 19 2026 at 15:51):

cargopete updated PR #13410.

Wasmtime GitHub notifications bot (May 19 2026 at 15:52):

cargopete has marked PR #13410 as ready for review.

Wasmtime GitHub notifications bot (May 19 2026 at 15:52):

cargopete requested dicej for a review on PR #13410.

Wasmtime GitHub notifications bot (May 19 2026 at 15:52):

cargopete requested wasmtime-wasi-reviewers for a review on PR #13410.

Wasmtime GitHub notifications bot (May 19 2026 at 15:52):

cargopete requested fitzgen for a review on PR #13410.

Wasmtime GitHub notifications bot (May 19 2026 at 15:52):

cargopete requested wasmtime-default-reviewers for a review on PR #13410.

Wasmtime GitHub notifications bot (May 19 2026 at 16:41):

pchickey commented on PR #13410:

Thank you for flagging the vetting issue. Yes, because accepting this crate into the wasmtime tree would require us (the Wasmtime maintainer team) to vet it, and we do not have the capacity to vet a 29kloc dependency, my opinion is that this crate should not land in Wasmtime. Your maintaining the crate elsewhere is, of course, welcome.

In general the long term solution that the Wasmtime team hopes for to solve this vetting problem is, in the wasip3 era we are hopefully entering soon, virtualization will finally work properly for implementations of the keyvalue interface to be made purely as a webassembly component that imports http, sockets or the filesystem.

Wasmtime GitHub notifications bot (May 20 2026 at 06:59):

:cross_mark: cargopete closed without merge PR #13410.

Wasmtime GitHub notifications bot (May 20 2026 at 07:00):

cargopete commented on PR #13410:

Thanks @pchickey — that's exactly the clarity I was looking for, and the WASIp3 virtualization point is a good north star to keep in mind.

The standalone crate is already published at https://github.com/cargopete/wasmtime-wasi-keyvalue-redb for anyone who needs an embedded persistent backend in the meantime. I'll follow the same pattern for a Redis backend.

Wasmtime GitHub notifications bot (May 20 2026 at 07:07):

cargopete commented on PR #13410:

Follow-up: the Redis backend is now also available as a standalone crate — https://github.com/cargopete/wasmtime-wasi-keyvalue-redis — which is the one that actually satisfies the Phase 2 portability criteria (Redis is explicitly listed). Same pattern, 6/6 tests passing against a live Redis instance.

Last updated: Jun 01 2026 at 09:49 UTC