SpacetimeDB Puts Server Logic Inside the Database, and It's Worth Taking Seriously

Most web applications follow the same layered pattern: a client talks to an application server, which talks to a database. The layers are clean, familiar, and carry decades of tooling. SpacetimeDB challenges whether that separation is necessary at all.

The premise is straightforward: instead of shipping data to an app server where logic runs, you ship the logic into the database. Modules written in Rust or C# get compiled to WebAssembly and executed within the SpacetimeDB process itself. Clients connect directly via WebSocket, subscribe to SQL queries, and receive incremental updates when the underlying data changes. There is no separate application layer.

This technical review on strn.cat walks through the architecture with useful specificity. The core abstractions are tables (standard relational), reducers (the mutation entry points, analogous to stored procedures), and subscriptions (the reactive query layer). A client calls a reducer to modify state; SpacetimeDB executes it in the WASM sandbox, commits the changes, and pushes diffs to all subscribed clients. The whole loop is handled by the database.

The appeal here is real. For multiplayer games, which is SpacetimeDB’s primary use case and where BitCraft Online runs on it in production, the subscription model maps cleanly onto what you actually want: every client sees a consistent, live view of the game world without you writing any synchronization logic. The infrastructure footprint is also genuinely smaller. One process instead of three.

What the Trade-offs Look Like

The architecture has costs that are worth naming clearly.

First, the WASM sandbox is a constrained environment. Standard library support varies, async is limited, and debugging is harder than running ordinary application code. You are writing server logic in a form factor that was designed for portability, not developer ergonomics.

Second, SpacetimeDB is currently a single-node system. For many workloads that is fine, but it sets a ceiling that a distributed database or horizontally scaled app tier does not have. The project is aware of this and is working on it, but it is not solved yet.

Third, and more subtly, collapsing layers means losing the natural seams where you would normally plug in middleware, authentication services, rate limiting, or observability tooling built for HTTP. You are not just adopting a database; you are adopting an architecture that sits outside the ecosystem most teams already operate in.

Who This Is Actually For

The honest answer is that SpacetimeDB is compelling for workloads that are inherently stateful, real-time, and where every client needs a coherent shared view of a rapidly changing world. Games fit this description. Collaborative editing tools might. Most CRUD web applications probably do not need it, and shoehorning a subscription-first architecture onto request-response semantics would be working against the grain.

That said, the ideas here are interesting beyond the immediate use case. Reactive query propagation and logic-in-database are not new concepts, but the execution is more polished than prior attempts. The WASM module system is a cleaner isolation boundary than traditional stored procedures. Whether this becomes a general-purpose pattern or stays specialized is an open question, and the review is worth reading for anyone thinking about where the server-database boundary should actually live.