SpacetimeDB for AI Builders: Drop the API Layer

If you've built an agent stack past the demo stage, you know the shape: Postgres holding state, an API server sitting between your agents and that state, Redis for pub/sub so services can talk to each other, and a WebSocket layer bolted on so the frontend isn't stuck polling. Four services. Four things that can silently drift out of sync at 3am while an agent is mid-task.

SpacetimeDB collapses that into one process. Your agent's logic runs inside the database itself, and every connected client — another agent, a dashboard, a human watching a run — gets state changes pushed to it the instant they commit. No API to maintain, no separate realtime service, no polling loop.

What it actually does

SpacetimeDB is a database that also runs your server code. You write functions called reducers — in Rust, C#, or TypeScript — that execute as atomic transactions directly inside the database process. A client calls a reducer, the reducer reads and writes tables, and every client subscribed to those tables gets the delta immediately over a persistent WebSocket connection, usually in single-digit milliseconds.

There's no REST endpoint you wrote sitting in the middle translating requests into queries. The client subscribes to a SQL-like query against a table, and the database keeps that subscription live for as long as the connection is open.

Clockwork Labs built this to run BitCraft Online, a multiplayer game where thousands of clients need to read and write shared world state without anyone polling for updates. That's a harder problem than most SaaS backends ever face, and it happens to be almost exactly the problem multi-agent AI systems have: several independent processes that need to see the same state change the moment it happens, without you hand-building the plumbing for it.

Why this matters if you're building agents

An agent without persistent, shared state is just a chatbot with better prompts. The usual fix is Supabase or Postgres for storage, an API route so the agent can read and write it, and something like Pusher or Ably layered on top if you want a frontend to update live instead of refreshing. That's three separate integrations doing the job of one feature.

With SpacetimeDB, the agent calls a reducer. The dashboard subscribes to a table. When the agent commits a change, the dashboard updates — no webhook you own, no polling interval to tune, no race condition from one service lagging a beat behind another.

It gets genuinely useful once more than one agent is involved. Multiple agents writing to the same tables, with every subscriber seeing the change the instant it lands, is coordination without a coordination layer — which is the part of multi-agent systems that actually breaks in production, long after the demo has convinced everyone it works.

Worked example: a shared task queue for three agents

Here's a concrete build: a researcher, a writer, and an editor agent pulling work off one shared queue, with a dashboard watching live.

1. Install and scaffold locally:

curl -sSf https://install.spacetimedb.com | sh
spacetime start
spacetime init --lang typescript agent-queue
cd agent-queue

2. Define the schema. In server/index.ts, a tasks table and a claimTask reducer that assigns work atomically, so two agents can't grab the same row:

import { table, reducer, ReducerContext } from "@clockworklabs/spacetimedb-sdk";

@table({ name: "tasks", public: true })
export class Task {
  id: number;
  status: "pending" | "claimed" | "done";
  claimedBy: string;
  payload: string;
}

@reducer
export function claimTask(ctx: ReducerContext, taskId: number, agentName: string) {
  const task = Task.filterById(taskId);
  if (!task || task.status !== "pending") return;
  Task.update({ ...task, status: "claimed", claimedBy: agentName });
}

3. Publish it:

spacetime publish agent-queue

4. Each agent connects and pulls work:

const client = new SpacetimeDBClient("ws://localhost:3000", "agent-queue");
client.subscribe(["SELECT * FROM tasks WHERE status = 'pending'"]);
await client.call("claimTask", [taskId, "researcher-agent"]);

5. The dashboard subscribes to the same table, zero extra code: client.on("tasks:update", render) shows every claim and completion the moment it happens, across all three agents, with no separate realtime service.

Because claimTask runs as one atomic transaction inside the database, there's no window where the researcher and writer both believe they own task #12. That race condition is normally something you'd hand-roll with a Postgres row lock or a Redis SETNX — here it's just how reducers work.

SpacetimeDB vs. Supabase + Pusher

| | SpacetimeDB | Supabase + Pusher/Ably | |---|---|---| | Moving parts | 1 (database + logic) | 3+ (DB, API layer, realtime service) | | Real-time sync | Automatic on any subscribed table | You wire the channels yourself | | Multi-writer coordination | Atomic reducers, built in | You build the locking yourself | | Query flexibility | Limited — no complex JOINs, no BI tooling | Full Postgres, great for reporting | | Ecosystem | Small, moving fast | Huge — extensions, ORMs, tutorials | | Hosted offering | Early access | Mature, production-proven |

If you need heavy analytical queries or you're already leaning on Postgres extensions and Row Level Security, don't migrate — the switching cost isn't worth it for a reporting problem SpacetimeDB isn't built to solve. If you keep bolting a pub/sub layer onto every new feature, it's worth a weekend before you build integration number four.

Common mistakes

• Using it as a drop-in Postgres replacement. SpacetimeDB is built for real-time operational state, not analytics. Keep a real Postgres instance around for BI dashboards and complex JOINs.
• Reading state in your client, deciding what to do, then calling a reducer to write it. That reintroduces the exact race condition reducers exist to eliminate. Put the decision logic inside the reducer itself, so it's part of the same atomic transaction.
• Leaving every table public: true. It's the fastest way to a working demo, but it also means any connected client can read that table's full contents. Scope visibility once you're past prototyping.
• Starting in TypeScript because your team knows it best. The TypeScript SDK is newer than the Rust one — thinner docs, more rough edges. If stability matters more than familiarity, start in Rust and treat TypeScript as the client side only.

FAQ

Is SpacetimeDB production-ready?

Self-hosted, yes — it's running a real multiplayer game at scale today. The hosted cloud offering is still early access, so if you want someone else managing the infrastructure, budget time for that gap or plan to self-host in the meantime.

How is this different from Supabase Realtime or Firebase?

Supabase and Firebase bolt real-time sync onto a database you still query through an API you maintain. SpacetimeDB removes that API layer entirely — logic runs inside the database as reducers, and clients subscribe straight to tables. Less to wire up, but a much smaller ecosystem if you need a feature SpacetimeDB doesn't already support.

Can multiple agents really write to shared state without conflicts?

Yes, and it's the main reason to use this over a standard database for agent work. Reducers run as atomic transactions, so two agents can't both "win" a race the way they could with a plain read-then-write. You still have to design the reducer to resolve the conflict — like claimTask checking status before writing — but the database guarantees the transaction boundary for you.

---

→ Ask the index what to build your database stack

→ Free credits for these tools

Written by McKlaud AI. Want to know which AI tools actually fit your business? Get a free AI audit.