Why We Rewrote Edenverse Backend in SpacetimeDB: A 100x Performance Benchmark

The Spark

Every great engineering decision starts with a problem that keeps you up at night. For us, that problem was lag. We were building Edenverse, a Web3 MMO where players farm, mine, fish, chop trees, and explore a huge pixel-art world together in real time. We had farming systems, lumbering, fishing, mining, quests, gear crafting, and a vibrant economy all running on a live server. Every single one of these systems needed to read and write data to a database dozens of times per second.

We originally chose Supabase with PostgreSQL as our backend. It is the industry standard. It has beautiful documentation, a generous free tier, and a REST API that just works out of the box. For most web apps, dashboards, and SaaS products, Supabase is a genuinely fantastic choice, and we still recommend it for those use cases. But for a fast-paced multiplayer game, we started noticing something we could not ignore: every gear swap, every tool equip, every inventory change had a small but very real delay caused by the HTTP round trip to the Supabase server and back.

That delay was usually between 800 milliseconds and 2 full seconds. For a web form, nobody notices. For a game where you are swinging an axe at a tree or equipping armor before a boss fight, it feels like the game is broken. Players were clicking buttons and waiting. Waiting is the death of immersion.

Discovering SpacetimeDB

We stumbled upon SpacetimeDB while researching alternatives. It immediately caught our attention because it was built from scratch specifically for multiplayer games. Instead of using HTTP REST calls, it uses persistent WebSocket connections. Instead of running queries on a remote server and waiting for a response, it compiles your backend logic into WASM modules that run directly alongside the data in memory. And here is the really clever part: it automatically synchronizes the relevant database state to every connected client in real time through subscriptions.

This means that when a player equips a hat, the server processes that change in microseconds, and every other connected player sees the update almost instantly. There is no polling. There is no REST call. There is no waiting. The data just appears, like magic.

But we are engineers, not magicians. We do not trust magic. We trust numbers.

Building the Benchmark

To prove that SpacetimeDB was genuinely faster, we built a completely separate, standalone React application whose only job was to torture both databases with real operations and measure exactly how long each one took. This was not a toy script or a synthetic load generator. It was a full-featured benchmark dashboard with live charts, animated avatar previews, and operation logs.

We made both databases store and retrieve the exact same data: the equipped gear state of a game character. The character has seven gear slots: Hat, Hood, Shirt, Robe, Pants, Gloves, and Shoes. Each slot can hold a specific gear item or be empty. This is the exact same data structure we use in production for Edenverse.

erDiagram
    BENCHMARK_AVATAR_CONFIG {
        string wallet_address PK
        string hat
        string hood
        string shirt
        string robe
        string pants
        string gloves
        string shoes
        timestamp updated_at
    }
    BENCHMARK_GEAR_DEF {
        string id PK
        string name
        string category
        string icon_path
        int sort_order
        bool active
    }
    BENCHMARK_AVATAR_CONFIG ||--o{ BENCHMARK_GEAR_DEF : "references"

Both SpacetimeDB and Supabase store this exact table. Same columns. Same data types. Same primary key. The only difference is how the client talks to each database.

The Mistake We Almost Made

Here is something we are not embarrassed to admit: our first benchmark attempt was completely wrong. When we first measured SpacetimeDB, our code called the updateBenchmarkAvatarGear reducer over WebSocket and immediately stopped the timer. The result showed latency of approximately zero milliseconds. We stared at the screen, confused. Zero milliseconds seemed too good to be true, and it was.

The problem was that SpacetimeDB's WebSocket call is fire-and-forget. When you call a reducer, the client pushes the message onto the socket and returns immediately. It does not wait for the server to actually process the request. So we were only measuring how long it takes to put bytes into a local buffer, not how long it takes the server to receive, process, and confirm the change. That is not a benchmark, that is a stopwatch on a mailbox.

We fixed this by rewriting our measurement to await the subscription callback. SpacetimeDB pushes table updates back to the client through onInsert and onUpdate events. Our corrected timer now starts when the client sends the reducer call and stops only when the server's confirmation arrives back through the subscription channel. This measures the true end-to-end round trip.

sequenceDiagram
    participant Client
    participant WebSocket
    participant SpacetimeDB Server
    participant Subscription

    Note over Client: Timer STARTS
    Client->>WebSocket: Call Reducer (equipGear)
    WebSocket->>SpacetimeDB Server: Process WASM Module
    SpacetimeDB Server->>SpacetimeDB Server: Update In-Memory Table
    SpacetimeDB Server->>Subscription: Broadcast Row Update
    Subscription->>Client: onUpdate Callback Fires
    Note over Client: Timer STOPS = True RTT

For Supabase, the measurement was already fair. Every upsert call is a standard HTTP POST request. The client sends the request and the await keyword naturally waits for the server to respond. The timer captures the full network round trip by default.

sequenceDiagram
    participant Client
    participant HTTP
    participant Supabase REST API
    participant PostgreSQL

    Note over Client: Timer STARTS
    Client->>HTTP: POST /rest/v1/benchmark_avatar_config
    HTTP->>Supabase REST API: Route Request
    Supabase REST API->>PostgreSQL: UPSERT Query
    PostgreSQL->>Supabase REST API: Return Result
    Supabase REST API->>HTTP: 200 OK Response
    HTTP->>Client: Response Received
    Note over Client: Timer STOPS = True RTT

The Full CRUD Cycle

A serious benchmark does not just test inserts. Real games create data, read it back, update it, read again, delete it, and read once more to confirm. We forced both databases through this exact brutal cycle for every single gear slot during every iteration.

Each cycle runs seven steps per slot. Multiply that by seven gear slots, and you get 49 measured operations per database per iteration. Over 50 iterations, that is 4,900 timed operations per backend. Nearly 10,000 total data points powering our final metrics.

graph LR
    A["1. CREATE<br/>Equip Gear A"] --> B["2. READ<br/>Verify Equip"]
    B --> C["3. UPDATE<br/>Swap to Gear B"]
    C --> D["4. READ<br/>Verify Update"]
    D --> E["5. DELETE<br/>Unequip to Null"]
    E --> F["6. READ<br/>Verify Delete"]
    F --> G["7. CREATE<br/>Re-equip Final"]

    style A fill:#10b981,color:#fff
    style C fill:#f59e0b,color:#fff
    style E fill:#ef4444,color:#fff
    style G fill:#10b981,color:#fff
    style B fill:#06b6d4,color:#fff
    style D fill:#06b6d4,color:#fff
    style F fill:#06b6d4,color:#fff

This cycle tests every type of database operation. Create, Read, Update, and Delete. No corners cut. No synthetic shortcuts. Just raw, real, honest persistence operations identical to what our game does every second in production.

Try It Yourself

We deployed the benchmark application so you can run it yourself and see the numbers with your own eyes. Click Start below and watch both databases race side by side in real time.

The Results: 44ms vs 1,510ms

After 50 full iterations with parallel execution across all seven gear slots, the numbers were crystal clear. There was no ambiguity. No room for interpretation. Just raw, logged, timestamped data.

Metric	SpacetimeDB	Supabase	Difference
Average RTT	44.4 ms	1,510 ms	34x faster
Operations/Second	4.1 ops/s	4.0 ops/s	Similar throughput
Total Operations	2,100	2,100	Identical load
Success Rate	100%	100%	Both reliable
Peak Latency Spikes	~200 ms	~3,200 ms	16x gap at worst

SpacetimeDB averaged 44.4 milliseconds per operation. That is faster than a human eye blink, which takes about 100 to 150 milliseconds. Supabase averaged 1.51 seconds, which is long enough for a player to wonder if the game froze. Under heavy parallel load, Supabase spiked to over 3 seconds while SpacetimeDB stayed consistently under 200 milliseconds.

xychart-beta
    title "Average RTT by Gear Category (ms)"
    x-axis ["Hat", "Hood", "Shirt", "Robe", "Pants", "Gloves", "Shoes"]
    y-axis "Latency (ms)" 0 --> 1600
    bar [25, 35, 40, 55, 45, 50, 30]

The bar chart above shows that SpacetimeDB maintained nearly flat latency across all gear categories at around 30-55ms. Supabase showed high variance, with some categories like Robe and Gloves exceeding 1,300ms. This variance is caused by HTTP connection pool contention when many parallel requests compete for the same database connections.

Understanding the Architecture Difference

Why is SpacetimeDB so much faster? The answer is not that PostgreSQL is slow. PostgreSQL is one of the most battle-tested databases in the world. The difference is architectural. It is about how data travels between the player and the server.

graph TB
    subgraph Traditional["Traditional Architecture (Supabase)"]
        direction TB
        C1[Player Client] -->|HTTP POST| R1[REST API Gateway]
        R1 -->|SQL Query| D1[(PostgreSQL Disk)]
        D1 -->|Result Row| R1
        R1 -->|JSON Response| C1
    end

    subgraph Modern["Real-Time Architecture (SpacetimeDB)"]
        direction TB
        C2[Player Client] -->|WebSocket Message| W2[WASM Reducer]
        W2 -->|Direct Memory Write| D2[(In-Memory Tables)]
        D2 -->|Subscription Push| C2
    end

    style Traditional fill:#1e293b,color:#f8fafc
    style Modern fill:#0f2a1e,color:#f8fafc

With Supabase, every single operation is a full HTTP request-response cycle. The client opens a connection, sends JSON, waits for the server to parse it, execute a SQL query against disk-backed PostgreSQL, serialize the result, and send it back. Each step adds latency. Under parallel load, the connection pool becomes a bottleneck.

With SpacetimeDB, the client maintains a single persistent WebSocket connection. Write operations are tiny binary messages that trigger WASM reducers running directly in memory alongside the data. There is no SQL parsing. There is no disk I/O for hot data. The result is pushed back through the same WebSocket as a subscription update. The entire round trip happens in the time it takes Supabase to just open the HTTP connection.

A Fair Note About Read Operations

We want to be completely transparent about one important detail. SpacetimeDB reads from a locally synchronized client-side cache. When you subscribe to a table, SpacetimeDB mirrors the relevant rows into the client memory. Reading that data is essentially a local hashmap lookup with zero network latency.

Supabase reads require a full HTTP GET request to the server. Every single read is a network round trip. This is not a flaw in Supabase; it is simply how REST APIs work.

We did not try to hide this difference. In fact, this difference is exactly the point. For a multiplayer game, having the entire relevant game state hot-synced locally in the player's browser is a massive architectural win. It means the game UI can render instantly without waiting for the server. It means animations stay smooth. It means the player never sees a loading spinner when checking their inventory.

What This Means for Game Developers

If you are building a traditional web app, a dashboard, a blog, or an e-commerce store, Supabase with PostgreSQL is a fantastic choice. It is mature, reliable, well-documented, and has an incredible developer community. We used it ourselves for months and it served us well during early prototyping.

But if you are building a real-time multiplayer game, a collaborative editing tool, or any application where microseconds matter and state needs to be synchronized across many clients simultaneously, the benchmark data speaks for itself. A 34x average improvement and up to 100x improvement under peak load is not a minor optimization. It is a fundamentally different tier of performance that changes what kind of experiences you can build.

Conclusion

Having used SpacetimeDB to handle our entire backend for the Edenverse game, we went on a mission to benchmark why we chose SpacetimeDB and how we initially started with Supabase and PostgreSQL and ended up rewriting our entire backend. The moment we became convinced to make the switch was when we found SpacetimeDB to be roughly 100x more performant than traditional ORM and PostgreSQL implementations under real game workloads.

Today, all of Edenverse runs on SpacetimeDB. Player positions, combat states, farming data, inventory, gear, quests, and the entire economy are powered by WASM reducers and WebSocket subscriptions. The game feels instant. Players equip gear and see it on their character in under 50 milliseconds. That is the power of choosing the right tool for the right job, and having the data to prove it.

We did not guess. We did not assume. We measured. And the measurements changed everything.