SpacetimeDB for AI Builders: Drop the API Layer

Most solo builders running AI agents have quietly assembled the same franken-stack: a Postgres DB for state, an Express or FastAPI server to query it, a Redis layer for pub/sub, and a WebSocket server so the frontend doesn't feel dead. Four services, four bills, four things to debug at 2am.

SpacetimeDB is a direct attack on that pattern.

What It Actually Does

SpacetimeDB is a database where your server logic runs inside the database. Clients subscribe to tables directly over WebSocket — there's no REST API sitting in between. When state changes, subscribers get the delta automatically. That's it. That's the whole pitch.

Clockwork Labs built it to power BitCraft Online, a massively multiplayer game that needs thousands of simultaneous clients reading and writing shared state with sub-100ms latency. The result is a system that's genuinely overbuilt for most web apps — but fits AI agent workloads surprisingly well.

You write your business logic as reducers (think: server functions) in Rust, C#, or TypeScript. These reducers run in the database process itself. A client calls a reducer → the DB executes it → subscribers see the updated tables in real time. No round-trips through an API you wrote.

Why AI Builders Should Care

Agents need persistent state. An agent that can't remember what it did five minutes ago is just a chatbot.

The typical stack for giving an agent memory: Supabase or Postgres for storage, an API route to read/write it, and if you want real-time agent-to-frontend sync, you're reaching for Pusher or Ably on top of that. Suddenly you're maintaining integrations.

With SpacetimeDB, your agent calls a reducer directly. The frontend subscribes to the relevant tables. When the agent updates state, the UI reflects it — no polling, no webhooks you wrote yourself, no race conditions from eventual consistency across services.

For multi-agent setups this gets more interesting. Multiple agents can write to shared tables, and any subscriber — another agent, a dashboard, a human operator — sees the changes in real time. Coordination without a coordination layer.

Getting Started

SpacetimeDB has a hosted cloud (still in early access) and a self-hosted option. For local dev:

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

# Start a local instance
spacetime start

# Create a new module (TypeScript)
spacetime init --lang typescript my-agent-module
cd my-agent-module && spacetime publish

Your module defines tables (the schema) and reducers (the logic). A minimal example — an agent memory table:

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

@table({ name: "agent_memory", public: true })
export class AgentMemory {
  key: string;
  value: string;
  updated_at: Timestamp;
}

@reducer
export function upsertMemory(ctx: ReducerContext, key: string, value: string) {
  AgentMemory.db.upsert({ key, value, updated_at: ctx.timestamp });
}

On the client side (your frontend or another agent), you subscribe to the table and call reducers:

const client = new SpacetimeDBClient("ws://localhost:3000", "my-agent-module");
client.subscribe(["SELECT * FROM agent_memory"]);
client.on("agent_memory:insert", (row) => console.log("New memory:", row));
await client.call("upsertMemory", ["current_task", "analyzing wallet history"]);

That's a real-time agent memory system with zero API code.

Honest Pros and Cons

Where it wins:

• Eliminates the API layer entirely — less code, fewer moving parts
• Real-time by default — no polling or webhooks to wire up
• Battle-tested under actual game-scale load (BitCraft is live)
• Open source, self-hostable, no lock-in

Where it's mid:

• TypeScript module support is newer than Rust — you may hit rough edges
• The "reducers live in the DB" mental model takes adjustment if you're used to REST
• Ecosystem is small. No Prisma, no ORM you recognize, no 1000-result Stack Overflow thread for your problem
• Not the right tool if you need complex relational queries or heavy analytics — it's built for real-time operational state, not reporting
• Cloud offering is early access; self-hosting means ops burden

If your agent just needs simple key-value persistence and you're already on Supabase, the switching cost probably isn't worth it. But if you're building a system where multiple agents or users interact with shared state in real time, this is legitimately the most elegant architecture available right now.

Who Should Try This Now

• Agent builders running multi-agent pipelines where coordination state needs to be shared and observable
• Game or simulation builders — this is what SpacetimeDB was made for
• Solo builders who are tired of gluing services together — if you're paying for Supabase + Pusher + API hosting separately, run the numbers
• Anyone building a real-time dashboard over agent activity

If you're shipping a standard CRUD web app or a basic LLM wrapper, use something simpler. Postgres + Supabase is fine. But if your architecture keeps wanting a pub/sub layer and you keep duct-taping one in, SpacetimeDB is worth a weekend.

Check it out on AI Bazaar.

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