Async key-value forbevy_db
A cross-platform persistence crate for Bevy — one game-facing API, two storage engines, every read and write kept off the game thread so the schedule never stalls.
Never blocks the frame
I/O is dispatched off the game thread via bevy_tasker. Systems poll DbRequest handles with try_recv() to drain results without blocking.
- Native — redb, a pure-Rust B+tree store on disk.
- WASM — rexie over IndexedDB in the browser.
What it gives you
Features
One API, two backends
The same Db handle works on native and WASM; the backend is selected at compile time.
Off-thread I/O
All persistence work is dispatched through bevy_tasker, so game systems never block on disk or IndexedDB.
Poll-based results
Pending operations return a DbRequest that systems drain with try_recv(), fitting naturally into a Bevy schedule.
Backend-agnostic errors
A single DbError enum abstracts over redb and IndexedDB failure modes.
Get started
Usage
use bevy::prelude::*;
use bevy_db::{BevyDbPlugin, Db, DbRequest};
App::new()
.add_plugins(BevyDbPlugin::default())
.run();Questions
Frequently asked
What does the bevy_db crate do?
It provides async key-value persistence for Bevy with a single game-facing API and two backends — redb, a pure-Rust B+tree, on native platforms and rexie over IndexedDB in the browser on WASM.
How does bevy_db avoid stalling the game loop?
All disk and IndexedDB I/O runs off the game thread through the bevy_tasker crate. Game systems poll DbRequest handles with try_recv to drain results without blocking the schedule.
What is the public API surface of bevy_db?
BevyDbPlugin initializes the backend and inserts the Db resource, Db is the request handle for get, put, and delete, DbRequest is the pending async result polled with try_recv, and DbError is the backend-agnostic error enum.