Does your app need to update itself on screen? If so, you’ll hear the usual answer: “You need a real-time database.” It’s a natural assumption, and an expensive one when it’s wrong. SpacetimeDB 2.0, released in February 2026, is a good case for testing it.
This piece covers what the database does, what it has proven, why no business market has been shaken by it yet, what its licence allows, and what a Quebec business should keep in mind. The thread running through it: pick a database by how often it gets written to, because a screen that feels live says nothing about the engine behind it. Call that mistake real-time by reflex.
What SpacetimeDB does: the logic lives in the database
A conventional database stores information. Your application server decides what to do with it, and your clients (browser, phone) fetch the result or wait for a signal.
SpacetimeDB puts the application’s code inside the database. You write server modules, in TypeScript among other languages. The database runs them, and subscribed clients receive each change the moment it happens. The server stays the judge: if two users touch the same row at the same instant, one transaction wins. Logic and data ship as one piece, which matters for a simulation or for writes that fight over the same row (official repository, v2.11.0).
“2.0” arrived on February 20, 2026, as tag v2.0.1. The latest release, v2.11.0, is dated October 7, 2026. The 2.x line added stable TypeScript modules, views that limit what each user can read, a sign-in service built on OpenID Connect, and, from v2.8.1, an endpoint that lets AI agents call the database’s functions directly (vendor release notes).
What it has proven: games
Production evidence comes from games. A specialist report says the documented workloads come mostly from the vendor, Clockwork Labs: its own game BitCraft, unnamed customers running many separate databases, and its own benchmarks (runtimewire.com). Those benchmarks are disputed, and the vendor conceded part of the criticism (a close reading of them).
Outside games, we found small open-source projects: a stream overlay, a university notes suite, a workspace where AI agents are users, a trading-card collection manager. No commercial product outside gaming turned up in three searches. Missing evidence after three searches doesn’t prove absence, but it’s the most honest signal available.
The project’s README claims a fit for everyday apps, collaboration tools, live dashboards, and chat. That’s the vendor talking, with no adopter example behind it. One developer who shipped a game on the database writes that for several SaaS and collaboration uses, the competitor Convex “may honestly be the better choice” (an unverified account).
Why it hasn’t shaken a market yet
Four reasons. The first is our reading; the other three rest on cited facts.
- The gain is narrow. The database makes one class of system easier: shared state that changes often, with the server as referee. A waiting list or status board that moves a few times a minute gains nothing over the tools you already have.
- The limits are structural. See the table below.
- The licence rules out the product sold to many customers. More below.
- The vendor’s funding deserves a look. It has raised about $26.3M in total, and the latest round we found, a $22M Series A, dates from June 2022 (Tracxn). One report says its closest rival raised $57M in August 2026.
The limits to know before you choose
| Limit | What we found |
|---|---|
| One thread per database | One global lock per database, and your module code runs inside it. Several sources agree. |
| Data held in memory | Every table lives in RAM, so memory sets the ceiling. The write log is flushed to disk asynchronously. |
| Storage beyond RAM | The vendor promises it for October 31, 2026. Not shipped yet. |
| Offline writes | We found no mention in the documentation or the client references. One source only, so verify before any mobile project. |
| Backups when self-hosting | No procedure described in the documentation we read. |
| Minimum version | Release notes report an identity-impersonation flaw fixed in v2.10.0 and a durability bug fixed in v2.9.0. Aim for v2.10.0 or later. |
A community deployment template adds three warnings in its notes. Keep the data volume and the signing keys, or every issued identity stops working. A full write log refuses new writes. And a bare node authenticates nobody, so anyone who finds the address could publish a module onto it. That’s a community report, not the vendor’s documentation.
The documentation and the release notes also disagree on how stable a few features are, procedures and views among them. Test whatever you depend on, on the version you plan to pin.
The licence: one production instance, no database service
SpacetimeDB ships under the Business Source License 1.1. Use is allowed, provided your application “uses the Licensed Work with no more than one SpacetimeDB instance in production” and you don’t use it “for a Database Service.” That last term means a commercial offering where third parties create tables whose schemas they control. On September 15, 2031, the licence converts to the GNU Affero GPL v3, with a linking exception.
“Instance” is undefined. The vendor’s FAQ says each database runs an independent instance of your module and that many databases can share one host. Does the licence count processes or databases? That’s unanswered, and only the vendor can settle it.
Our reading, which isn’t legal advice: an application for your own company, or a system built for a single client on its own instance, fits the licence. One instance per customer, or hosting for other developers, doesn’t. If you plan to sell a product to many clients, have a lawyer check the licence or get the vendor’s answer in writing before you write a line of code.
Four questions that tell you if a conventional database is enough
Do several people write to the same state several times a second? Must the server settle competing writes in a single transaction, such as a live auction bid or the last available seat? Does a server-side clock need to move the state forward, as in a simulation? Should each user see only their own slice of the data?
If none of these describes your need, stay with what you have. If one or more applies and your users are online, a trial of SpacetimeDB is justified. Live auctions are a real example: a bid is a contested write, and the closing time is a scheduled row.
| Your need | What to look at first |
|---|---|
| A board that changes a few times a minute | Supabase Realtime, open source. Self-hosted defaults: 500 events per second, 1,000 users per channel |
| Staff editing in the field with no signal | A sync engine (Zero, ElectricSQL, PowerSync), built for offline use. Zero lists $30, $300, or $1,000+ a month |
| An ordinary collaboration product sold to many customers | Convex: friendlier licence that converts to Apache after two years, self-hostable, $25 per developer a month |
| Small live rooms on Cloudflare | Cloudflare Durable Objects, billed by usage |
Offline is the quiet disqualifier. A phone in a warehouse, or at an event door with weak signal, has to write first and sync later. That’s a sync engine’s job, and this database doesn’t offer it.
What Quebec adds: Law 25 and section 17
Section 17 of Quebec’s Act respecting the protection of personal information in the private sector requires a privacy impact assessment and a written agreement before personal information is communicated outside Quebec. Another province counts as outside (Commission d’accès à l’information). The section sets an equivalence test and bans nothing.
SpacetimeDB’s hosted service raises a specific problem. The vendor is a Delaware company, and its privacy policy, dated 2023, names no hosting region (privacy policy). We found no statement of where hosted data sits. For any project touching personal information, the hosted service means one assessment per project.
A server you run in Quebec avoids that assessment for that data flow. It settles section 17 and nothing more, and the workload moves to you: updates, backups, keys, and monitoring, on a database whose documentation describes no backup procedure. A server in Toronto won’t help, since Ontario is outside Quebec too.
On the hosted side, the tiers are listed in dollars: free (2,500 credits a month, about 3 million calls, paused when idle), $25 a month (100,000 credits, replication, point-in-time backups kept 7 days), $250 a month (a reserved node, backups kept 30 days), then per-node pricing. The vendor calls the price list a beta, subject to change (pricing page).
The principle to keep
Choose your database by how often it’s written to and who settles the conflicts. How live the screen feels doesn’t matter. A board that moves a few times a minute is happy on a conventional database, and a phone with no signal needs an engine that writes offline.
If you’re weighing two databases for a real project, the first consultation is free: write to us.