Let's talk benchmarks | Blog | SpacetimeDB

25K STARS<br>Login<br>Community

installLogin

ALL POSTSLet's talk benchmarks

May 14th, 2026 · Tyler Cloutier<br>In March, we announced SpacetimeDB 2.0 alongside a benchmark that claimed SpacetimeDB could process over 100,000 end-to-end transfer transactions per second. The video and our posts on social media picked up a lot of attention, and in some cases drew criticism for what some felt was misleading benchmarking, especially from competitors whose products did not perform well in our testing.

Recently, we discovered and fixed several issues in SpacetimeDB, which unfortunately do make the benchmark numbers we published at that time misleading, and for that we apologize. Thing is, they're just not misleading in the way you might expect. The problem wasn't with the benchmark, but with SpacetimeDB itself. It wasn't living up to its true potential.

In particular, after we improved our V8 threading model, SpacetimeDB is now able to process 303,920 ± 4,712 transactions per second in our TypeScript benchmark. That’s an improvement of almost 200% over our original benchmark numbers, which hovered at around 100,000 transactions per second. Because we focused primarily on V8 performance, TypeScript is now actually faster than Rust, which measures only 265,541 ± 940 transactions per second in our benchmark.

Naturally, we’ve updated the graphs on our homepage accordingly!

We’ve even added error bars! We would have added error bars for the competitor backends as well, but we're not working with enough pixels. In fact, we had trouble getting the overall throughput for Convex, PlanetScale, and CockroachDB to show up at all on 1080p screens, so today we’re introducing a new feature…

2x Zoom!

We want to ensure that our benchmarking results are accessible for all users no matter the resolution of their screens.

Why wait so long?<br>Now, I like some good Twitter banter as much as the next guy, but since we announced 2.0, the team and I have been called “goons”, “liars”, “morons”, “dishonest”, “deceptive” and that our database is “just Redis”, “doesn’t offer replication”, “doesn’t provide ACID guarantees”, that our benchmark was not “comparative” or “apples-to-apples”, and that SpacetimeDB is “not a very good database”. All of which is untrue, of course. Much of this came from PlanetScale, a company who claims to pride themselves on “technical diligence”. However, they did effectively no diligence at all before making broad, sweeping, and incorrect technical claims about our product. Not a great look if you ask me.

We haven’t addressed all of that in a single place, yet. In fact, we’ve been largely silent since releasing our original video.

In the spirit of “technical diligence,” we wanted to take the last several weeks to carefully address the criticism raised about our benchmarking. So let’s finally separate the truth from the lies, explore why we chose this benchmark, why we believe it is an important benchmark, and why SpacetimeDB performs so well on this benchmark (spoiler: contrary to popular assumption it has nothing to do with it being an “in-memory” database).

Let’s start by understanding the benchmark and the criticism.

What is SpacetimeDB?

If you’re not familiar with SpacetimeDB, it is a backend framework that runs your server logic in the same process as the database. The core idea is to combine the server and database into a single integrated system. Not only does this dramatically simplify your code, it also dramatically improves performance. It’s also a very old idea: stored procedures. The difference between SpacetimeDB stored procedures and Postgres stored procedures, for example, is all about usability and user experience. SpacetimeDB lifts stored procedures to be a first-class feature of the database. You upload all of your server logic as a single module which defines your schema, functions, and types. As the app developer, you write in whatever general purpose programming language you like and we use Wasm and JS to run it inside the database.

The Benchmarks

In our benchmark, featured prominently in the 2.0 announcement video, we imagine a simplified banking or accounting application wherein users can make balance transfers between accounts. The benchmark measures transfer throughput, or the number of transfer transactions a given backend stack can process per second. The throughput is measured according to application clients by measuring the number of successful transfer transactions within a window. It is also a full end-to-end benchmark, meaning that we are measuring the performance of the full backend stack including both web server and database together. SpacetimeDB and Convex both combine the server and database into a single platform. For other stacks, we specify both the backend runtime and the database management system.

For reference, here is the SpacetimeDB implementation of the server-side transfer endpoint presented in its entirety:

export...