# Description of Changes AI app generation benchmark comparing SpacetimeDB vs PostgreSQL (Express + Socket.io + Drizzle ORM). Same AI model (Claude Sonnet 4.6), same prompts, same chat app, two backends. Upgraded through 12 feature levels, manually graded at each level, bugs fixed, all costs measured via OpenTelemetry. Results viewable at: https://spacetimedb.com/llms-benchmark-sequential-upgrade ## Benchmark harness (`tools/llm-sequential-upgrade/`) - `run.sh`: orchestrates headless Claude Code sessions for code generation, sequential upgrades, and bug fixes. Tracks all API costs via OTel. Supports `--upgrade`, `--fix`, `--composed-prompt`, `--resume-session` modes. - `grade.sh` / `grade-agents.sh`: grading harnesses for manual testing of generated apps. - `docker-compose.otel.yaml`: OTel collector + PostgreSQL services. - `generate-report.mjs` / `parse-telemetry.mjs`: aggregate per-session telemetry into cost reports. - Backend guidelines in `backends/`: SpacetimeDB SDK reference, config templates, server setup docs, PostgreSQL setup with Drizzle/Socket.io guidance. **After https://github.com/clockworklabs/SpacetimeDB/pull/4740 merges, we will likely want to update this so that it reads backend and SDK guidance from SKILLS** ## Two complete benchmark runs **Run 1 (20260403):** Original methodology. **Run 2 (20260406):** Refined methodology with domain bias removed from SpacetimeDB SDK docs and PostgreSQL instructions made feature-spec-neutral. **Note: no meaningful changes in results were observed with these changes. Domain familiarity biases were very small and almost certainly not the cause of STDB's major gains over PG stack.** Each run contains full L1-L12 app source for both backends, level snapshots preserving state before each upgrade, and per-session OTel cost summaries. ## 12 feature levels | Level | Feature | |---|---| | L1 | Basic Chat + Typing + Read Receipts + Unread Counts | | L2 | Scheduled Messages | | L3 | Ephemeral Messages | | L4 | Message Reactions | | L5 | Message Editing with History | | L6 | Real-Time Permissions (kick, ban, promote) | | L7 | Rich User Presence | | L8 | Message Threading | | L9 | Private Rooms + Direct Messages | | L10 | Room Activity Indicators | | L11 | Draft Sync | | L12 | Anonymous to Registered Migration | ## Results | | Run 1 (20260403) | Run 2 (20260406) | |---|---|---| | **SpacetimeDB total cost** | $13.33 | $12.62 | | **PostgreSQL total cost** | $17.80 | $19.68 | | **SpacetimeDB bugs** | 5 | 2 | | **PostgreSQL bugs** | 19 | 8 | | **SpacetimeDB fix sessions** | 4 | 1 | | **PostgreSQL fix sessions** | 17 | 10 | Both runs agree: SpacetimeDB apps are cheaper to build, have fewer bugs, and require fewer fix iterations. The refined methodology (Run 2) widened the cost gap and **confirmed the advantage is structural, not an artifact of domain-biased SDK docs.** ## Performance benchmark (`perf-benchmark/`) Stress throughput tool that fires concurrent writers at peak saturation against the AI-generated `send_message` handlers. | Tier | SpacetimeDB (avg) | PostgreSQL (avg) | Ratio | |---|---|---|---| | AI-generated (as-shipped) | 5,267 msgs/sec | 694 msgs/sec | 7.6x | | PG rate limit removed | 5,267 msgs/sec | 1,070 msgs/sec | 4.9x | | Optimized (same features kept) | 25,278 msgs/sec | 1,139 msgs/sec | 22x | The gap widens with optimization because SpacetimeDB's bottleneck is fixable code patterns in the reducer while PostgreSQL's bottleneck is architectural (sequential network round-trips to an external database). Optimized reference code with all features preserved is in `perf-benchmark/results/optimized-reference/`. ## Data handling Per-session cost summaries (`cost-summary.json`, `COST_REPORT.md`, `metadata.json`) are committed. Raw OTel telemetry (`raw-telemetry.jsonl`) containing PII is excluded via `.gitignore` and stored privately. # API and ABI breaking changes None. All changes are in `tools/llm-sequential-upgrade/`. No production code, library, or SDK changes. # Expected complexity level and risk **1 - Trivial.** Self-contained benchmarking tooling and data. No interaction with production code. # Testing - [x] L1-L12 upgrades completed on all 4 apps (2 backends x 2 runs) with OTel cost capture - [x] All levels manually graded after each upgrade; bugs filed and fixed via the harness - [x] Methodology refinement between runs validated (domain bias removal, feature-neutral instructions) - [x] Stress benchmarks run across both runs x 3 tiers (as-shipped, rate-limit-removed, optimized) - [x] Optimized benchmarks verified to preserve all original features - [x] Sensitive data (PII in raw telemetry) removed from repo and gitignored - [ ] Reviewer: spot-check that METRICS_DATA.json / METRICS_REPORT.json numbers match the telemetry cost-summary.json files --------- Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
AI One-Shot App Generation
This project benchmarks how well Cursor rules enable AI to one-shot SpacetimeDB apps — generate and deploy a working app in a single attempt.
Purpose
This benchmark compares AI-generated apps across two platforms:
- SpacetimeDB — Real-time database with automatic client sync
- PostgreSQL — Traditional database requiring manual WebSocket broadcasting
By generating equivalent apps for both platforms, we can evaluate how well Cursor rules guide the AI to produce working SpacetimeDB applications compared to a familiar baseline (PostgreSQL).
How to Run a Benchmark
Prerequisites
- Install Cursor IDE (free download)
- Have a Cursor subscription or API credits for the model you want to test
- For SpacetimeDB tests: install the SpacetimeDB CLI
- For PostgreSQL tests: have Docker installed (for the database container)
Step-by-Step Instructions
-
Open this folder as a workspace in Cursor
- File → Open Folder → select
tools/llm-oneshot - This folder must be the workspace root so Cursor loads the
.cursor/rules/files
- File → Open Folder → select
-
Open a new Agent chat
- Press
Ctrl+I(Windows/Linux) orCmd+I(Mac) to open the AI panel - Or click the Cursor icon in the sidebar
- Press
-
Select your model
- Click the model dropdown at the bottom of the chat panel
- Choose the model you want to benchmark (e.g., Claude Opus 4.5, GPT-5, Gemini 3 Pro)
-
Add the prompt files
Drag these two files from the file explorer directly into the chat:
apps/chat-app/prompts/language/typescript-spacetime.md(or your desired stack)apps/chat-app/prompts/composed/12_full.md(or your desired feature level)
Then type this message:
Read all rules first. Do not reference AI-generated apps in apps/ for guidance. Execute these prompts. -
Let the AI generate the app
- Press Enter to send the prompt
- The AI will read the rules, then generate the backend and client code
- Do not interrupt — let it complete the full generation
-
Deploy when prompted
- The AI will ask if you want to deploy (Local / Cloud / Skip)
- Choose "Local" to test the app on your machine
Why isolate from existing apps? To ensure clean results. If the AI references previous attempts, we can't tell whether success came from the rules or from copying.
Example Configurations
TypeScript + SpacetimeDB (full features):
- Language:
apps/chat-app/prompts/language/typescript-spacetime.md - Level:
apps/chat-app/prompts/composed/12_full.md
TypeScript + PostgreSQL (full features):
- Language:
apps/chat-app/prompts/language/typescript-postgres.md - Level:
apps/chat-app/prompts/composed/12_full.md
Available Stacks
| Language File | Stack |
|---|---|
typescript-spacetime.md |
TypeScript + SpacetimeDB (React) |
typescript-postgres.md |
TypeScript + PostgreSQL (Express) |
Feature Levels
Each level is cumulative.
| Level | Features Added |
|---|---|
| 01 | Basic Chat, Typing, Read Receipts, Unread |
| 02 | + Scheduled Messages |
| 03 | + Ephemeral Messages |
| 04 | + Reactions |
| 05 | + Edit History |
| 06 | + Permissions |
| 07 | + Presence |
| 08 | + Threading |
| 09 | + Private Rooms |
| 10 | + Activity Indicators |
| 11 | + Draft Sync |
| 12 | + Anonymous Migration (ALL) |
After Generation
The AI will ask (per deployment.mdc rules):
- Deploy? — Local / Cloud / Skip
- Grade? — AI reviews the code and writes a
GRADING_RESULTS.mdfile
Grading
Grading is done manually, with AI doing a shallow pass before manual review. The grading rubric is in apps/{app}/prompts/grading_rubric.md.
Each graded app gets a GRADING_RESULTS.md file in its folder.
Aggregating Results
To generate summary reports from all graded apps:
cd tools/llm-oneshot
pnpm install
pnpm run summarize
This outputs to docs/llms/:
oneshot-summary.md— Combined summary with feature scoresoneshot-grades.json— Structured data for websites
Folder Structure
Generated apps are stored in:
apps/{app-name}/{language}/{model}/{platform}/{app-name}-{YYYYMMDD-HHMMSS}/
Example:
apps/chat-app/typescript/opus-4-5/spacetime/chat-app-20260107-120000/
apps/chat-app/typescript/opus-4-5/postgres/chat-app-20260108-140000/
This structure allows comparing results across:
- Apps — chat-app, paint-app
- Models — opus-4-5, grok-code, gemini-3-pro, gpt-5-2
- Platforms — spacetime vs postgres