SpacetimeDB: a relational database that runs your game or web server as a module

The server tier SpacetimeDB removes, and who feels that removal

The project's own framing is blunt: it is a relational database that is also a server. You upload application logic into the database, and clients connect to it with nothing in between. Instead of a web or game server that owns the schema, validates requests and pushes updates, the schema and the logic live together as a module, and the database process handles both.

The README describes the payoff as writing your entire application in a single language and deploying it as a single binary, listing the things you no longer run: a separate webserver, containers, Kubernetes, VMs, and a cache layer added later. That list is the honest description of the audience. This is for teams whose backend is mostly request validation, permission checks and fan-out of state changes to connected clients. Multiplayer games are the obvious case. The README states that the entire backend of the MMORPG BitCraft Online runs as a single SpacetimeDB module, covering chat, items, terrain and player positions, synchronized to thousands of players.

The same architecture is a poor fit for a backend whose value is in long-running batch jobs, third-party API orchestration, or heavy per-request computation. Those want a process you can scale horizontally and restart at will. A module runs inside the database, and the repository's own layout reflects that constraint: crates/execution, crates/runtime and crates/engine are separate concerns from crates/client-api because the execution environment is the product.

Modules, tables, reducers and subscriptions: the actual data flow

A module defines two things: tables, which hold your data, and reducers, which hold your logic. Clients connect, call reducers, and subscribe to tables. When a reducer runs and changes table state, the database synchronizes that state to every subscribed client in real time. Permission and authorization logic goes inside the module, in the same language as the rest of your application, rather than in a middleware layer.

The durability model is stated plainly in the README: all application state is held in memory for fast access, while a commit log on disk provides durability and crash recovery, with ACID guarantees comparable to a traditional RDBMS. That combination explains both the latency profile and the memory requirement. Every table you define is resident, so a schema with a large cold table costs RAM whether or not anyone queries it. The repository's crate list shows the machinery behind this: crates/commitlog, crates/durability, crates/snapshot and crates/datastore are separate components, and crates/subscription is its own crate rather than a feature of the query layer.

Modules are written in Rust, C#, TypeScript or C++, with quickstart links per language in the README. The Cargo.toml workspace members list confirms the surface area: sdks/rust and sdks/unreal are workspace members, alongside modules/module-test, modules/sdk-test and a family of sdk-test-* modules for views, procedures, event tables and case conversion. Those test modules are the clearest signal of which features the project treats as first-class, because each one exists to exercise a specific binding.

Installing SpacetimeDB and publishing a first module

The README gives a three-step quick start. On macOS or Linux the installer is a shell script piped to sh, and on Windows PowerShell there is a separate installer URL. Both install the spacetime CLI.

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

# Windows (PowerShell)
iwr https://windows.spacetimedb.com -useb | iex

After that, log in. The README states that spacetime login opens a browser to authenticate with GitHub, and that your identity is linked to your account so you can publish databases.

spacetime login

Then create a project from a template. The README's example uses the chat-react-ts template, and says the command creates the project, publishes it to Maincloud, and watches for file changes, rebuilding and republishing on save.

spacetime dev --template chat-react-ts

That third step depends on a hosted service, and the README points at the pricing page for details rather than stating costs. If you want to avoid that dependency, the repository ships a Dockerfile and a docker-compose.yml. The compose file builds from crates/standalone/Dockerfile, maps port 3000 for the database and 5432 for Postgres, and starts the server with an entrypoint that runs cargo watch against crates/standalone with --data-dir=/stdb/data plus JWT key paths. That is a development container, not a hardened deployment: it mounts source directories, runs privileged, and enables flamegraph and Tracy profiling through SPACETIMEDB_FLAMEGRAPH_PATH and SPACETIMEDB_TRACY.

What the module model costs you

The strongest objection to SpacetimeDB is not performance, it is coupling. Your schema, your business logic and your authorization rules become one artifact deployed as one binary. The README presents this as the point, and for a game world it is. For a system where the schema evolves independently of the code that reads it, or where several teams own different tables, a single deployable module is a coordination problem rather than a simplification.

The in-memory model is the second constraint. State is held in memory with a commit log for durability, which means the working set is bounded by the machine's RAM, and the commit log is the recovery path. The README does not document rollback behavior, so if your operational plan depends on reverting a published module to a previous version, that is something to establish from the docs before you commit, not something the README answers.

Third, the client model assumes persistent connections and subscriptions. A client subscribes to tables and receives updates. That is wasteful for a workload that reads a report once a day, and it puts you in the position of writing your logic in Rust, C#, TypeScript or C++ rather than in whatever language your data team already uses. The quickstart links in the README cover Rust, C#, TypeScript and C++ only, and the Cargo.toml workspace members include sdks/rust and sdks/unreal. Treat Python as unconfirmed by what the repository documents.

SpacetimeDB versus Postgres plus a realtime layer

The natural comparison is a conventional relational database with a separate realtime mechanism on top. Postgres holds the data, a server process owns the logic, and something like WebSockets or a change-data-capture pipeline pushes updates to clients. In that arrangement the database is a component you can replace, back up with standard tooling, and query from any language with a mature driver. SpacetimeDB trades that replaceability for removing the middle tier entirely: no server process, no separate pub/sub, and authorization expressed in the module rather than in middleware.

The difference in approach shows up in where the query language lives. SpacetimeDB has crates/sql-parser, crates/query, crates/physical-plan and crates/expr in the workspace, so SQL exists, but it is an internal component of a system whose primary interface is reducers and subscriptions, not a wire protocol that arbitrary clients speak. If your requirement is that any BI tool, ORM or psql session can connect, that requirement is better served by Postgres. If your requirement is that a thousand players see each other's state changes without you operating a message broker, the module model is the shorter path.

A second comparison worth making is against serverless backends that also bundle logic with storage. Those typically keep a network hop between the function and the data, and they bill per invocation. SpacetimeDB's claim is different in kind: the logic executes where the data already is, in memory, and the README states the system provides ACID guarantees with the speed of an optimized web server. Whether that holds for your access pattern is something only your own load test can answer.

Licence, releases and the cost of tracking upgrades

The repository's badge identifies the licence as BSL 1.1, and the licence file is LICENSE.txt at the repository root. The GitHub metadata reports the licence as NOASSERTION, which is what you get when a licence text does not match a recognized SPDX pattern. BSL 1.1 is a source-available licence with terms that typically restrict production use of a hosted or competing service, and those terms change over time. Read LICENSE.txt yourself and get your own legal review; nothing here is legal advice, and the specific grant matters more than the label.

On maintenance, the project is not archived, and the last push was on 2026-09-19. Releases have been frequent: v2.9.0 on 2026-09-01, v2.10.0 on 2026-09-04 and v2.10.1 on 2026-09-15, all minor or patch increments within a two-week window. That cadence is good news for fixes and bad news for anyone pinning a version and expecting the module API to sit still. The workspace is large, spanning crates/, sdks/, modules/, templates/ and tools/, and the bindings crates (crates/bindings, crates/bindings-macro, crates/bindings-sys) are where an upgrade is most likely to reach your code.

The practical upgrade cost is the recompile-and-republish cycle. Because the module is the deployable artifact, a binding change means rebuilding and republishing rather than bumping a client library. Budget for that, and pin the CLI version you install alongside the module toolchain rather than tracking latest.

Editorial conclusion

Adopt SpacetimeDB when your application is a shared, mutable world that many clients watch at once and you are willing to write your logic as a module in Rust, C#, TypeScript or C++. Do not adopt it for read-heavy analytics, for a schema you need to reshape weekly, or if you are not prepared to run the database as your server. Verify first that the language binding you need is in the sdks/ and crates/bindings directories at the version you plan to pin, and read LICENSE.txt before you design around the BSL 1.1 terms.

Frequently asked questions

Official sources

1. clockworklabs/SpacetimeDB on GitHub
2. Issues
3. Project website
4. README
5. Releases