SpacetimeDB Puts the Server Inside the Database, and That Changes the Mental Model
Source: lobsters
Most backend architectures follow the same shape: a database sits on one side, an application server on the other, and every request is a negotiation between them. SpacetimeDB throws that shape out. The server logic runs inside the database. Not as stored procedures bolted onto a SQL engine, but as first-class WebAssembly modules that share the same process as the storage layer.
A recent technical review on Lobsters works through what this means concretely, and it surfaces some useful tensions.
What the architecture actually looks like
The core primitive in SpacetimeDB is the reducer: a function, written in Rust or C#, that atomically reads and writes database tables. Clients do not issue ad-hoc queries. Instead, they subscribe to SQL-like filter expressions, and the runtime maintains those subscriptions incrementally, pushing diffs whenever relevant rows change. The result is that the server never explicitly sends messages; it just mutates state, and the subscription layer handles propagation.
This is an elegant fit for multiplayer games, which is the primary use case. In a game, you typically want every client to see a consistent view of world state, and you want that view to update in near-real-time. The subscribe-and-diff model maps directly onto that requirement without any bespoke sync code.
Where it gets complicated
The review notes some practical friction. The query language is a subset of SQL, which means anything complex gets pushed into reducer logic rather than query expressions. That is a reasonable tradeoff if you trust your module runtime to stay fast, but it shifts complexity from a well-understood layer (SQL) to a less well-understood one (WASM module performance and scheduling).
There is also the operational surface to consider. Running user code inside the database process is powerful, but a misbehaving module can affect the whole system in ways that a misconfigured application server cannot. The isolation boundary is WASM, which is real but not the same as process isolation.
The column-oriented storage design performs well for the subscription update path, where you often need to scan a single column for changes, but it is less obviously good for the mixed read/write workload that games produce under load.
Whether the tradeoff is worth it
For the specific problem SpacetimeDB targets, the architecture is coherent. Eliminating the round-trip between application server and database removes a whole category of latency and consistency headaches. Reducers as the single mutation interface make reasoning about state changes tractable. The subscription model means you do not need a separate pub/sub layer.
The question is whether those benefits hold outside the game use case. General-purpose web services have different shapes: more heterogeneous query patterns, less predictable client counts, more pressure on the SQL surface area. SpacetimeDB’s constraints that feel freeing in a game context start to feel restrictive there.
The technical review is worth reading if you have been curious about the project. It stays grounded in specifics rather than marketing claims, which is the kind of analysis that actually helps you decide whether a tool belongs in your stack.