SpacetimeDB: The Database That Ate Your Server

The Heresy That Works

Every web application you have ever shipped follows the same pattern: clients talk to a server, the server talks to a database, and you spend the rest of your career managing the stuff in between. Load balancers, API gateways, caching layers, ORM configurations, deployment pipelines. The actual business logic is maybe 20% of the work. The infrastructure is the other 80%.

SpacetimeDB says: what if the database was the server? Not metaphorically. Literally. You write your application logic as a "module," compile it to WebAssembly, upload it into the database, and clients connect directly. No Express. No Django. No Kubernetes. No containers.

This sounds like stored procedures with extra steps. It is not. Stored procedures run SQL strings inside a database process. SpacetimeDB modules are full programs in real languages, compiled to WASM, running with access to typed table APIs, automatic schema migrations, and a subscription system that pushes state changes to clients in real time.

How It Actually Works

The mental model is straightforward. You define tables and reducers. Tables hold your data. Reducers are functions that modify your data inside ACID transactions. Clients subscribe to tables and get real-time updates whenever the data changes. That is the entire programming model.

// Define a table
#[spacetimedb::table(accessor = messages, public)]
pub struct Message {
    #[primary_key]
    #[auto_inc]
    id: u64,
    sender: Identity,
    text: String,
}

// Define a reducer (your API endpoint)
#[spacetimedb::reducer]
pub fn send_message(ctx: &ReducerContext, text: String) {
    ctx.db.messages().insert(Message {
        id: 0,
        sender: ctx.sender,
        text,
    });
}

On the client side, you subscribe and the data just appears. No polling. No refetching. No manual cache invalidation.

// React client: subscribe and get live updates
const [messages] = useTable(tables.message);
// messages updates automatically when server state changes

The reducer pattern borrows from functional programming. Each reducer runs as a transaction: either all changes commit or none do. This gives you the same ACID guarantees as a traditional RDBMS, but the "stored procedure" is a full Rust, C#, TypeScript, or C++ program rather than SQL strings glued together with PL/pgSQL.

The WASM Trick

The key enabling technology is WebAssembly. Rust, C#, and C++ modules compile to WASM and run inside the database process via Wasmtime. TypeScript modules run on V8. This means your module code executes in the same address space as the database engine, with all data already in memory.

There is no serialization overhead. No network round-trip between "the app" and "the database." When your reducer reads a row, it is reading from an in-memory data structure directly. When it writes, the write goes into the same in-memory store and simultaneously into a durable commit log on disk.

This is why SpacetimeDB can process 170,000 transactions per second for Rust modules and over 100,000 for TypeScript. The database and the application share a single process, a single memory space, and a single event loop.

BitCraft: The Proof by Fire

SpacetimeDB was not built in a vacuum. Clockwork Labs is a 40-person game studio backed by $26.3M from Andreessen Horowitz, with angel investors including the CEOs of CCP Games, Roblox, and Unity. They needed a backend for BitCraft, their MMORPG on Steam.

The entire BitCraft backend runs as a single SpacetimeDB module. Chat, inventory, terrain generation, crafting, NPC behavior, and the real-time positions of thousands of concurrent players. All of it lives in tables, all of it runs through reducers, and all of it synchronizes to clients automatically.

This is the strongest possible validation for a database system. MMORPGs are the hardest real-time synchronization problem in software. If SpacetimeDB can handle thousands of players moving, fighting, building, and chatting simultaneously with ACID guarantees, your SaaS dashboard will be fine.

The BitCraft server code is open source, so you can study how a production MMORPG maps onto the module/table/reducer model. It is one of the more instructive codebases on GitHub.

The Subscription Model

Real-time sync is not bolted on. It is the core abstraction. Clients subscribe to queries, and SpacetimeDB automatically pushes differential updates whenever the underlying data changes. This eliminates the single biggest source of bugs in multiplayer applications: stale client state.

When a reducer inserts, updates, or deletes a row, SpacetimeDB evaluates which client subscriptions are affected and pushes only the relevant diffs over WebSocket. You never write synchronization code. You never build a pub/sub layer. You never debug why one client has stale data.

SpacetimeDB 2.0 introduced "views" as well. Views are read-only functions that compute derived data from your tables. Clients can subscribe to views the same way they subscribe to tables, and the views update automatically. Think of them as materialized queries that stay fresh without any manual cache invalidation.

Language Support: Write Once, Deploy Anywhere

Server modules can be written in Rust, C#, TypeScript, or C++. Client SDKs exist for TypeScript (covering React, Next.js, Vue, Svelte, Angular, Node, Bun, and Deno), Rust, C# (including Unity), and C++ (including Unreal Engine).

The C# and Unreal bindings are not an afterthought. They are a strategic bet. Game developers live in Unity and Unreal. By meeting them where they already work, SpacetimeDB avoids the adoption friction that kills most developer tools.

The Competitive Landscape

SpacetimeDB occupies a unique position. It is not competing with PostgreSQL or MySQL on the traditional database axis. It is not competing with Firebase or Supabase on the BaaS axis. It is competing with the concept of having a separate server at all.

The benchmark story is striking. In SpacetimeDB's keynote comparisons, the system processed over 150,000 transactions per second on workloads where competing solutions managed a fraction of that throughput. A Hacker News analysis of their 2.0 benchmarks acknowledged the raw performance while noting the architectural tradeoff: SpacetimeDB runs single-node and in-process, so it trades horizontal scalability for vertical speed.

The Single-Node Tradeoff

Here is the honest tension. SpacetimeDB keeps all application state in memory on a single machine. This is what makes it fast. It is also what limits its scalability ceiling. You cannot shard a SpacetimeDB module across multiple nodes the way you can scale a PostgreSQL cluster.

BitCraft handles this by running multiple SpacetimeDB databases, each responsible for a spatial partition of the game world. This works for games where the world can be divided into zones. For web applications, a single machine with enough RAM can handle surprisingly large workloads when there are no network hops eating your latency budget.

The team is aware of this constraint. For many use cases, vertical scaling on modern hardware (64+ core machines with terabytes of RAM) is more than sufficient. But if your application needs to scale beyond what a single beefy machine can handle, you will need to architect your own sharding strategy.

Getting Started in 60 Seconds

The developer experience is deliberately frictionless.

# Install
curl -sSf https://install.spacetimedb.com | sh

# Login
spacetime login

# Create, publish, and watch a project from a template
spacetime dev --template chat-react-ts

Three commands and you have a live, real-time application running on their managed cloud (Maincloud). The spacetime dev command watches for file changes and automatically rebuilds and republishes on save. Hot-reload for your entire backend.

You can also self-host with Docker:

docker run --rm --pull always -p 3000:3000 clockworklabs/spacetime start

The pricing changed significantly in late 2025. A free tier that is actually usable. Storage dropped from $10/GB/month to $1/GB/month. A referral program that permanently expands your monthly compute budget. The economics are designed to eliminate the "should I try this?" hesitation.

Under the Hood: The Crate Map

The repository is a Rust workspace with over 40 crates. The codebase is roughly 9 million lines of Rust, with significant TypeScript (2.3M lines for the SDK and tooling), C++ (3.8M lines for the C++ bindings), and C# (1.3M lines for the Unity and .NET bindings).

Key crates worth exploring:

• standalone -- the main SpacetimeDB server binary
• core -- the database engine, query evaluation, and transaction processing
• vm -- the WASM virtual machine integration (Wasmtime)
• subscription -- the real-time subscription and diff system
• commitlog -- the write-ahead log for durability and crash recovery
• sql-parser -- a custom SQL parser for SpacetimeDB's query language
• bindings -- the host-side module ABI (how WASM modules call into the database)
• datastore -- the in-memory storage engine

The SDKs live in /sdks with dedicated packages for Rust, TypeScript, C#, and Unreal. The TypeScript SDK supports React, Vue, Svelte, Angular, and vanilla JS through a single package.

The Licensing Question

SpacetimeDB uses the Business Source License 1.1 (BSL). This is the same license used by MariaDB, CockroachDB, and Sentry. It allows free use for most purposes but restricts offering SpacetimeDB as a managed service. The code converts to a permissive open-source license after a set period.

This is a pragmatic choice for a venture-backed company. It prevents cloud providers from offering a hosted SpacetimeDB without contributing back, while still letting developers use, modify, and self-host the software freely. Whether you consider BSL "open source" depends on your definition, but the source code is available and the development happens in public.

Who Should Care

SpacetimeDB is most compelling for three audiences.

Game developers who need real-time multiplayer backends without building custom networking stacks. The Unity and Unreal SDKs mean you can prototype a multiplayer game in days instead of months.

Indie developers and small teams who want to ship products without managing infrastructure. If your entire backend fits on one machine, SpacetimeDB eliminates the operational complexity that makes solo development so painful.

Real-time application builders who are tired of bolting WebSocket layers onto REST APIs. Collaborative editors, live dashboards, chat applications, and anything where multiple clients need to see the same data at the same time.

What to Watch

SpacetimeDB is moving fast. Version 2.0 landed in early 2026 with major performance improvements and the new views system. The project ships multiple point releases per week. The Discord community is active and the team is responsive.

The big question is whether the "database is the server" model can break out of gaming into mainstream web development. The technical foundation is strong. The developer experience is polished. The benchmarks are impressive. But paradigm shifts in how people build software take time, even when the new paradigm is objectively better.

If BitCraft continues to prove the model at scale, and if the web development community starts adopting SpacetimeDB for non-gaming use cases, this could be one of the more consequential open-source projects of the decade. The bet is bold. The execution so far is real.