Last week was super hot in databases.

All thanks to the release of SpacetimeDB 2.0, and their viral release video:

The video is pretty standard and solid for the most part. But starting from ~9:30 they start presenting performance benchmark results, comparing SpacetimeDB's performance with other popular DB providers and setups.

It all starts with Convex, which is likely the most loved backend+DB platform at the moment (it's really great, go try it out).

The SpacetimeDB CEO leads with "Convex speed compares to pen and paper." Meaning Convex is damn slow.

But not just Convex, all other databases appear to be crazy slow: PlanetScale (the most stable huge cloud), Supabase (the most popular startup Postgres hosting with dev plugins), CockroachDB (referred to as "webscale," mimicking another old-ass meme about MongoDB ). Damn, it's even faster than Node.js + SQLite running locally!

The ending of the video features some power metal song, and it's filled with memes about how SpacetimeDB crushes all their competitors.

The answer is simple, yet genius.

When optimizing backends, the most time-consuming operations are normally not related to database query execution time.The real latency is caused due to network round-trip from an app server to a database and back. SpacetimeDB solved this creatively: they put all the backend code execution right inside the database. So all your functions running inside the database are transactional by definition. Clients connect to the database directly and receive real-time updates. Code is deployed right into the database.

The DX overall looks pretty similar to Convex. Managed version spins up in 1 click, you can also self-host. But SpacetimeDB team created a standalone database with SQL support and (as they claim) ACID guarantees. In comparison, Convex uses PostgreSQL internally but abstracts it away as document storage.

This architecture is indeed fascinating. And at the same time, these ideas have been floating around in the database world for… checking my notes… 40 years! Stored procedures aimed to solve the very same problem, and first procedures appeared back in 1989!

The catch is that stored procedures are written in SQL, which turned out to be not so practical compared to writing application code in Python, PHP, Node.js, or literally whatever else.

SpacetimeDB implemented a TypeScript interface, so you can slop TS code that will run right inside the database. Easy to write, easy to deploy, and transactional by default.

The launch turned out to be controversial. Calling out competitors by name, joking about their non-existent performance, making too much fun of them — these things usually divide people. So even though there were a lot of people who learned about SpacetimeDB this way (me included), it also brought a wave of criticism from people experienced in databases and system design. It all boils down to one thing: the benchmarks aren't fair and the comparison is not correct.

The next day, Convex CEO replied with his article addressing this topic. In it he explained thatbenchmarketingis something that exists for ages. MongoDB was notably famous for it. Same was with Redis. He explains that there’s only so much you can optimise database and it’s all comes down to what tradeoffs you introduce into your system.

On twitter, he also recommends for people to go and try out SpacetimeDB as it looks like a "great pick". What a nice guy!

A few days later, Vicent Martí, the architect who previously worked at PlanetScale and GitHub, wrote up his in-depth research on how SpacetimeDB works internally, what transaction guarantees it can actually provide, and his hot takes on its architecture. The article is pretty funny yet detailed, and it concludes that SpacetimeDB is "a database product that is a hash table with a single lock in front of it." Yikes.

The CEO of PlanetScale retweeted the article, which gives it more weight.

Now, there's some level of public pressure on SpacetimeDB to provide a technical deep-dive and implementation details proving that their benchmarks aren't lying or comparing apples to oranges.

On March 2nd, the SpacetimeDB CEO made another interesting move and published an article called "Why you should choose Convex." It's actually a really solid in-depth piece explaining the strengths of both Convex and SpacetimeDB and comparing their pros and cons. It admits some limitations that weren't clear before (like it not being a full TypeScript runtime the way Convex is, or how real-time views work differently between the two). Really great article.

We have yet to see more benchmarks and research that explain the small but impactful differences between databases. But aside from the beef: isn't that cool that we have powerful hybrid backend frameworks now?

LLMs have opened up the opportunity to build low-level code fast and ship technical products with much smaller teams (which was really hard before). So we're going to see more modern real-time frameworks that bring outstanding DX, transactional safety, and real-time subscriptions. And I'm all for it!

I'm building with Convex and it's as great as it seems. It simplifies so many backend concepts into simple terms, which makes it really great for working with LLMs you can actually explain to an LLM how to write backend code on top of Convex abstractions. Excited to try SpacetimeDB too. Let's see how well it ages.