I recently came across SpacetimeDB, which promises impressive performance according to its docs, and I wanted to see how it would compare in practice.
So I built a small messaging benchmark for SpacetimeDB, Convex, and Supabase and ran all three locally on my Apple M1 Mac with 8 GB of RAM. I tested five workloads, from sending a single 1 KB message to sending 1,000 messages of the same size.
Here’s what I found.
The numbers
All three databases ran locally, without the usual network trip to a remotely hosted database.
| Messages | Size per message | Total payload | SpacetimeDB | Convex | Supabase |
|---|---|---|---|---|---|
| 1 | 1 KB | 1 KB | 18 ms | 21 ms | 176 ms |
| 10 | 32 KB | 320 KB | 69 ms | 178 ms | 271 ms |
| 50 | 1 KB | 50 KB | 31 ms | 609 ms | 322 ms |
| 100 | 8 KB | 800 KB | 132 ms | 1,511 ms | 1,014 ms |
| 1,000 | 1 KB | ~1 MB | 523 ms | 13,204 ms | 5,717 ms |
The biggest gap appears in the last row.
For 1,000 messages, SpacetimeDB took 523 ms, Convex took 13.2 seconds, and Supabase took 5.7 seconds.
That's about 25 times longer for Convex and 11 times longer for Supabase compared with SpacetimeDB in this particular test.
Why such a difference? To understand that, it's worth looking at how these databases work.
How the three databases work
The biggest differences are in how each system processes writes, accesses data, and delivers updates to connected clients.
SpacetimeDB
SpacetimeDB combines a database with server-side application logic. Its tables are kept in memory while the server runs, with data persisted to disk.
Clients can subscribe to queries and receive updates as the underlying data changes. This makes it possible to build applications where the server and connected clients stay in sync without having to build the entire update pipeline yourself.
Keeping data in memory can reduce the work needed to access it. Combined with its application model, this can help explain SpacetimeDB's strong performance in these tests.
Convex
Convex combines a database with server-side functions and reactive queries. Writes run through mutations, and clients can subscribe to queries that update when relevant data changes.
This model makes it convenient to build reactive applications. But the work involved in processing mutations and delivering updates can add up, particularly when many individual writes are involved.
Supabase
Supabase is a backend platform built around PostgreSQL. It provides SQL queries, transactions, bulk inserts, and real-time capabilities alongside the database.
PostgreSQL handles the data operations, while Supabase provides the surrounding APIs and services. How writes are grouped, how queries are executed, and whether additional features are involved can all affect performance.
These systems offer different approaches to building applications with live data. The database engine matters, but so do the operations being performed and how updates reach the client.
The workload matters
The ranking between Convex and Supabase changes depending on what we're doing.
With 10 messages of 32 KB each, Convex takes 178 ms, while Supabase takes 271 ms.
With 50 messages of just 1 KB each, Supabase takes 322 ms, while Convex takes 609 ms.
SpacetimeDB remains fastest in both cases, but Convex and Supabase trade places.
This is a good reminder that performance isn't one fixed number. Message size, the number of writes, how operations are grouped, and the work involved in delivering updates can all influence the result.
A database that performs well for one workload might not have the same advantage for another.
How much can we conclude?
A benchmark is only useful when we understand what it measures.
I ran each workload multiple times on the same machine, with all three databases running locally. This removes the usual remote database network trip, but the results still reflect this particular environment and the operations being measured.
The three systems also have different architectures and application models. This isn't a comparison of database engines in isolation; it's a comparison of how they handle these messaging workloads using their respective approaches.
That doesn't make the results less useful. It just defines what they tell us.
In this setup, SpacetimeDB was consistently fastest across all five workloads. In the largest test, it was about 25 times faster than Convex and about 11 times faster than Supabase.
Those are the measured results, not a guarantee that every application will see the same speedup.
So, which database would I choose?
It depends on the application.
- SpacetimeDB is worth exploring if you're building an application that needs fast data access and live updates, especially when you want the database and server-side application logic to work together.
- Convex offers a reactive application model that can make building synchronized, interactive experiences straightforward.
- Supabase is an appealing choice when you want PostgreSQL, SQL, and a broad set of backend services in one platform.
Performance is one part of the decision. Developer experience, ecosystem, deployment, scaling, data requirements, and the complexity of your application matter too.
But if we're looking strictly at the five messaging workloads in this benchmark, SpacetimeDB wins. No ties, no exceptions.
Try it yourself
I've put the benchmark in my GitHub repository so you can inspect the code and run the tests yourself. If you try it on a different machine, or with different workloads, I'd be interested to see how the results compare.
Because the most useful benchmark isn't just the one that produces an impressive number, but the one that helps us understand what happens when we build a real application.
And in this case, SpacetimeDB definitely got my attention.
Top comments (0)