irt.io vs SpacetimeDB
SpacetimeDB is a database that runs your server code. You define tables and transactional functions, and clients call those functions and subscribe to queries over the tables. irtio is a room server, and state lives in the room.
The structural difference is persistence. SpacetimeDB state is durable rows by default. irtio state is a live room that hibernates and wakes.
When SpacetimeDB is the better choice
- Your game is one persistent world, not a set of sessions. A world that keeps existing while nobody is in it, and that every player shares, is exactly what the model is for.
- You want your state to be a database. Tables, transactions and query-shaped access come with the product, and you get them without adding a second system.
- You want per-client views defined by query. Clients subscribe to the rows they need, and the subscription is the filter.
- You want server logic in Rust or C#, or a client outside the browser. irtio rooms are TypeScript and irtio clients are browser only.
When irt.io is the better choice
- Your game is session shaped. Room codes, matches, lobbies and party games map onto rooms directly, and a room that nobody is using costs nothing while it sleeps.
- You want continuous simulation with real physics. A room can step a Rapier or matter2d world at a fixed rate and sync bodies as ordinary fields.
- You want input to feel instant. Bodies a player steers can be predicted on the client and rebased on the server’s values every authoritative tick.
- You want the multiplayer extras included. Voice, quick match, simulated players and bandwidth profiling are part of the same package set.
Model comparison
| SpacetimeDB | irt.io | |
|---|---|---|
| Authority | Server, inside transactional functions | Server, per collection |
| Who operates the server | Its hosted service, or you self-host | irt.io |
| State model | Rows in tables, delivered by subscription queries | Schema of collections, synced as binary deltas |
| Prediction | You write it | Built in, one option on joinRoom |
| Physics | Not included | Rapier or matter2d, stepped in the room |
| Voice | Not included | joinVoice(room) |
| Testing | Your language’s own tools | In-process rooms with real clients, plus load runs |
| Idle rooms | State stays in the database, so there is nothing to wake | Rooms hibernate and wake with state intact |
| Language | Rust or C# modules, with client SDKs including TypeScript | TypeScript on both sides |
What porting looks like
Tables become collections. A table of players becomes an entity collection with one instance per player, and a table with a single row becomes a singleton. Field types come from the schema package, and every field has a fixed width, so pick the narrowest type that holds your values.
Transactional functions become RPCs. The handler shape is the same idea: the client asks, the server decides, the change is applied for everyone. Two rules differ. An irtio room handler is synchronous and cannot await anything, and it has no network or file access, so anything that called out has to move outside the room.
Subscriptions become visibility. Instead of a client asking for the rows it wants, the schema says who receives a collection: a role list, or a spatial grid around the client’s own position. A client cannot ask for a wider view than its role and position give it, which is stricter than a query and rules out a class of leak. It is also less flexible, and there is no query language.
Durability is the piece that needs a decision. Room state is live state, so anything that must
outlive the room moves to room.kv for per-player values or to a named save for a whole room.
Both are key based with no listing or scanning. If your design leans on querying stored data
across the whole game, that part belongs in a database of yours, or SpacetimeDB is the better
home for the game.
Next steps
- The mental model for rooms, owners and the schema.
- State and schema for collections and field types.
- RPCs for moving a decision to the server.
- Visibility for role and spatial views.
- Saves and restore and player storage.
- Hibernation for what happens to a quiet room.
This page describes each product’s model as it stood at the page’s last review. If something here is wrong or out of date, write to hello@irt.io and it gets fixed.