A benchmark suite comparing SpacetimeDB against traditional web application stacks for transactional workloads.

See SpacetimeDB's performance advantage with one command:

pnpm install
pnpm run demo

The demo compares SpacetimeDB and Convex by default, since both are easy for anyone to set up and run locally without additional infrastructure. Other systems (Postgres, CockroachDB, SQLite, etc.) are also supported but require more setup. The demo checks that required services are running (prompts you to start them if not), seeds databases, and displays animated results.

Options: --systems a,b,c | --seconds N | --concurrency N | --alpha N | --skip-prep | --no-animation

Note: demo always runs the built-in test-1 scenario. Use bench if you need to specify a test name directly. Note: demo selects targets with --systems; bench filters test connectors with --connectors.

All tests use 50 concurrent connections with a transfer workload (read-modify-write transaction between two accounts).

Key Finding: SpacetimeDB achieves ~14x higher throughput than the next best option (SQLite RPC) and maintains nearly identical performance under high contention (only ~4% drop), while traditional databases suffer significant degradation (CockroachDB drops 96%).

Note: SpacetimeDB runs on ARM architectures (including Apple M-series Macs), but has not yet been optimized for them.

The chart above shows TPS vs Zipf Alpha (contention level). Higher alpha values concentrate more transactions on fewer "hot" accounts, increasing contention. SpacetimeDB maintains consistent performance regardless of contention level, while traditional database architectures show significant degradation.

All systems were tested with out-of-the-box default settings - no custom tuning, no configuration optimization. This reflects what developers experience when they first adopt these technologies.

For cloud services, we tested paid tiers to give them their best chance:

• PlanetScale: PS-2560 (32 vCPUs, 256 GB RAM), single node, us-central1.
• Supabase: Pro tier
• Convex: Pro tier

All benchmarks follow an apples-to-apples comparison using the same architecture pattern:

Client → Web Server (HTTP) → ORM (Drizzle) → Database

Or for integrated platforms (SpacetimeDB, Convex):

Client → Integrated Platform (compute + storage colocated)

This ensures we're measuring real-world application performance, not raw database throughput.

Each transaction performs a fund transfer between two accounts:

1. Read both source and destination account balances
2. Verify sufficient funds in source account
3. Debit source account
4. Credit destination account
5. Commit transaction with row-level locking

This is a classic read-modify-write workload that tests transactional integrity under concurrent access.

docker compose run --rm bench -- --seconds 10 --concurrency 50 --alpha XX --connectors YY

• --seconds 10: Duration of benchmark run
• --concurrency 50: Number of concurrent client connections
• --alpha 0: ~0% contention (uniform account distribution)
• --alpha 1.5: ~80% contention (Zipf distribution concentrating on hot accounts)
• --stdb-compression none|gzip: SpacetimeDB client compression mode (default: none)

Server Machine (Variant A - PhoenixNAP):

• s3.c3.medium bare metal instance - Intel i9-14900k 24 cores (32 threads), 128GB DDR5 Memory, OS: Ubuntu 24.04

Server Machine (Variant B - Google Cloud):

• c4-standard-32-lssd (32 vCPUs, 120 GB Memory) OS: Ubuntu 24.04
• RAID 0 on 5 Local SSDs
• Region: us-central1

Client Machine:

• c4-standard-32 (32 vCPUs, 120 GB Memory) OS: Ubuntu 24.04
• Region: us-central1
• Runs on a separate machine from the server

Note: All services (databases, web servers, benchmark runner) except Convex local dev backend run in the same Docker environment on the server machine.

Running clients on separate machines ensures:

• Network round-trip latency is measured (realistic production scenario)
• Client CPU/memory doesn't compete with server resources
• Results reflect actual deployment conditions

• 100,000 accounts seeded before each benchmark
• Initial balance: 10,000,000 per account
• Zipf distribution controls which accounts are selected for transfers

The primary bottleneck in traditional web application architectures is the round-trip latency between the application server and database:

Traditional: Client → Server → Database → Server → Client
                        ↑___________↑
                     Network round-trip per query

SpacetimeDB eliminates this by colocating compute and storage:

SpacetimeDB: Client → SpacetimeDB (compute + storage) → Client

This architectural difference means SpacetimeDB can execute transactions in microseconds rather than milliseconds, resulting in order-of-magnitude performance improvements.

The benchmark supports pipelining for all clients - sending multiple requests without waiting for responses. This maximizes throughput by keeping connections saturated.

SpacetimeDB supports withConfirmedReads mode which ensures transactions are durably committed before acknowledging to the client. The benchmark results shown use withConfirmedReads = ON for fair comparison with databases that provide similar durability guarantees.

PlanetScale results (~477 TPS) demonstrate the significant impact of cloud database latency. When the database is accessed over the network (even within the same cloud region), round-trip latency dominates performance. This is why SpacetimeDB's colocated architecture provides such dramatic improvements.

See DEVELOP.md for prerequisites, configuration, and full CLI reference. The distributed TypeScript SpacetimeDB workflow is documented there as Run the distributed TypeScript SpacetimeDB benchmark.

Benchmark results are written to ./runs/ as JSON files with TPS and latency statistics.

See repository root for license information.