Check out our all new pricing plans! Learn more.
Community
We gave Claude two backends.
One shipped, one debugged.
Same AI. Same prompts. Same real-time chat app. One built on SpacetimeDB, one on a Postgres stack.
What we built and how
A real-time chat app, built one feature at a time, by the same AI, against two different backends. Here's what that actually means.
Each feature layers on top of the last. By the final level, the app has to keep presence, threads, private rooms, and drafts all in sync across clients in real time.
Claude works on one feature at a time and can't move on until it passes. Bugs are tracked, fix iterations are counted, and cost is tallied as it goes.
Both backends have to deliver the same real-time features to the same React client. They just get there differently.
Postgres costs compound. SpacetimeDB stays linear.
SpacetimeDB costs scale linearly with features added. Postgres doesn't. The gap widens as features interact.
Postgres burns 6× more on fixes
The Postgres stack has more wiring to get right. Every missed emit is a bug. Every bug is another fix loop. Every fix loop eats the budget meant for new features.
For every $1 SpacetimeDB spent on repairs, Postgres spent $6.22.
New features kept breaking Postgres
SpacetimeDB shipped twice as many features bug-free. Postgres bugs clustered where features had to interact with each other.
Most Postgres bugs were real-time failures
One in three Postgres bugs was state failing to sync across clients. SpacetimeDB's subscription model makes that entire category impossible to produce.
46% less backend. Zero wiring.
Declarative tables and reducers replace the Express, Socket.io, and Drizzle scaffolding Postgres requires. Fewer moving parts means fewer places for the AI to miss a connection.
- −SQL schema migrations (Drizzle)
- −Express REST endpoints per feature
- −Manual Socket.io room management
- −Per-event emit calls; miss one, break real-time
- −Auth middleware wired per endpoint
- +Declare tables as structs
- +Write reducers (functions that mutate state)
- +Clients subscribe to queries; updates are automatic
- +No WebSocket emit boilerplate
- +No SQL query strings
The AI-generated code runs faster too
Same chat app, same hardware, both pushed to peak throughput. Raw and optimized. SpacetimeDB leads in both.
The numbers, side by side
12 feature levels. Same AI model. Same prompts. Same app requirements. Figures averaged across 2 runs. The only variable was the backend.
| Metric | SpacetimeDB | Postgres |
|---|---|---|
| Total AI cost to buildAveraged across 2 runs | $12.98 | $18.74 |
| Features working first tryNo fix iterations needed | 75% | 46% |
| Bugs found per runAveraged across 2 runs | 3.5 | 13.5 |
| Fix iterations per runRepair loops required | 2.5 | 13.5 |
| Cost spent on fixesShare of total budget on repairs | $1.14 (9%) | $7.09 (38%) |
| Total lines of codeAI-generated, client + server, excl. CSS | 2,304 | 3,288 |
| Backend lines of codeAI-generated, server-side only | 777 | 1,451 |
| LLM API calls per runTotal prompts sent | ~395 | ~666 |
| Total build timeWall-clock, averaged | ~55 min | ~83 min |
How we ran this benchmark
The backend you choose determines whether your AI ships features or debugs them.
SpacetimeDB is a database with real-time subscriptions and server-side logic built in. No WebSocket glue, no ORM, no event routing layer.