Glonce

SpacetimeDB's launch benchmarks are misleading, review argues

infrastructureThe Glonce editorsHacker News🔥58Glonce rating58Impact48Novelty58Relevance70Surprise52Players32Credibility82

SpacetimeDB, a database that runs application code inside the database itself, launched version 2.0 with a marketing video mocking rival databases and a set of self-published benchmarks. A systems engineer identified on the article's own page as vmg, a Principal Systems Engineer who worked at GitHub from 2010 to 2020 and at PlanetScale from 2020 to 2025 before moving in 2025 to what the bio lists as 'SpaceXAI (via Cursor)', published a technical review of the launch on a personal blog. The review carries a dateline of 2026-02-26, about six months before this Hacker News discussion surfaced it, and its phrase 'earlier this week' describes that February launch rather than a recent one; the source gives no reason the older piece resurfaced now.

The review states upfront that the author finds SpacetimeDB's marketing distasteful, while still aiming to judge the underlying product fairly. Its central argument is that the launch benchmarks are not honest, not because the numbers are invented, but because they compare SpacetimeDB against multi-region, highly available distributed databases built on very different tradeoffs. The review illustrates the pattern with an example from the author's own past work: while at PlanetScale, the author's team shipped a fully transactional MySQL extension for vector similarity search that keeps vector data on disk. Run on the same EC2 instance, one loaded with 32GB of RAM and 64GB of vector data, that extension handled tens of thousands of queries per second, while pgvector, a Postgres extension that instead keeps its similarity graph in memory, took more than 3 seconds per query because its graph had to page to disk. The review says it would have been tempting to publish that gap as proof the extension was '10000 times faster than pgvector', but calls that framing dishonest since the two products serve different tradeoffs; PlanetScale published a technical breakdown of its design instead. It contrasts this with Turbopuffer, a search database whose own benchmarks are unremarkable and whose documentation dwells on its limits, yet which the author says is the best product on the market for the use cases it fits.

Applied to SpacetimeDB, the review argues the same pattern holds: it is an all-in-one database and application server where the application's own code runs inside the database, comparable in spirit to stored procedures in a relational database. Because that code sits next to the data with no network hop, while the competing databases SpacetimeDB is benchmarked against require a separate network request per query, its advantage on queries per second mostly measures the cost of that network round trip, which the review calls neither honest nor useful to a prospective customer. The review then explains why SpacetimeDB's writes are fast: the entire committed state of an instance sits behind one read-write mutex (Rust's parking_lot RWMutex, itself a port of WebKit's WTF::Lock), so writes execute strictly one after another; that makes linearizability trivial to prove, the author writes, because the system is, in effect, a hash table with a single lock in front of it. Because a read cannot run while a write is in progress either, the lock uses what the review calls 'eventual fairness' so a reader always eventually gets in, though it can be delayed at random by up to 0.5 milliseconds even under heavy write load. Writes run as reducers: user code compiled to WebAssembly and executed inside a Wasmtime virtual machine while the lock is held, during which no other reducer can run and nothing can read the database; SpacetimeDB's own documentation states that reducers 'cannot perform HTTP requests', for exactly that reason. A newer Procedures feature does allow expensive operations, including HTTP calls, and remains in Beta as of this release, with SpacetimeDB's documentation warning its API may still change; opening a transaction inside a procedure still takes the same global lock, so the review warns it must be committed quickly or the whole system stalls. Reads run through Views, a read-only counterpart to reducers that can run concurrently with each other under a shared reader lock, but never while a write is in progress.

On durability, SpacetimeDB keeps its dataset fully in memory and backs it with a write-ahead log that is not flushed synchronously as part of a write; instead it is flushed to disk asynchronously, by default every 50 milliseconds. An optional withConfirmedReads flag can make a read wait, sleeping on the server for up to 50 milliseconds, until it can confirm the data it is about to return has actually reached the log on disk; the review reads this as evidence the product targets 'mostly ephemeral' data where most queries do not need that guarantee. On scaling, a SpacetimeDB cluster option offers one primary instance with several eventually consistent follower replicas, but since both the application code and the data live inside that single primary instance, the whole system is bottlenecked by its CPU and RAM, and the only way to grow is a bigger machine. The review concludes this profile fits 'a more powerful Redis' far better than the relational, distributed systems SpacetimeDB chooses to benchmark itself against.

The review traces this design to SpacetimeDB's original purpose as the backend for an MMORPG, playable now on Steam, where losing 50 milliseconds of game state in a crash is a tolerable cost, and says the technical choices make sense for that use case. It compares the launch to MongoDB around 2011, which it says shipped an unimpressive database with impressive benchmarks, was mocked online for it, and only years later, after acquiring the WiredTiger storage engine, became what the author calls a serious, viable database company, fifteen years on, even though its early reputation still lingers unfairly. The author says that launching, in 2026, a database that is essentially 'a hash table with a single lock in front of it' would be done quietly, since cutting corners at launch is a path MongoDB proved workable; a marketing video with laser beams and a 'bottle of tears', however, only complicates paying back that reputational debt later. The review's sharpest criticism targets SpacetimeDB's pivot toward LLM and agentic-coding backends: SpacetimeDB's own marketing now says 'LLMs go much further with SpacetimeDB because it handles all the persistence, logic, deployment, and real-time sync in a single cohesive backend', but the author argues the same single-lock design that suited a game server makes the entire application's performance and availability, in the author's words, 100% dependent on short segments of user code running inside that one critical section, code whose freedom from side effects or delays cannot be enforced by the type system and depends on WebAssembly bytecode a JIT compiler generates at runtime; a bug there is likely to surface only in production and to degrade the whole application, potentially into an outage. The review sums up the fit for AI-written code bluntly: SpacetimeDB is, in the author's words, 'not the ideal environment for a LLM to program in'. It closes by saying the author still sees a real product and real lessons in SpacetimeDB, and speculates that a future SpacetimeDB v3 could isolate application code, allow long-running transactions without hurting others' performance, throttle runaway queries automatically, distribute itself without forcing an AI agent to design a distributed system by hand, and ship with fewer marketing benchmarks and more technical documentation.

Key facts

  • SpacetimeDB launched version 2.0 with a marketing video mocking rival databases and a set of self-published benchmarks; a technical review argues those benchmarks are not honest because they compare SpacetimeDB against distributed databases built on different tradeoffs, and points to a separately published benchmark set on GitHub that it says shows SpacetimeDB performing poorly against competitors.
  • The review's author, identified on the page as vmg, a Principal Systems Engineer previously at GitHub (2010 to 2020) and PlanetScale (2020 to 2025), published the piece with a dateline of 2026-02-26, about six months before this Hacker News discussion surfaced it.
  • SpacetimeDB wraps its entire committed database state in one global read-write mutex, so writes (called reducers) execute strictly one at a time and no read can proceed while a write is running; readers face up to a 0.5 millisecond random delay under the lock's eventual-fairness scheme even during heavy write load.
  • The database is fully in-memory and can scale only vertically, on a bigger single machine, since application code and data share the same instance; its write-ahead log flushes to disk asynchronously every 50 milliseconds by default, and an optional withConfirmedReads mode can add up to 50 milliseconds of read latency to confirm durability.
  • The review traces SpacetimeDB's design to its original use as an MMORPG game backend and compares its benchmark controversy to MongoDB's around 2011, but argues the same single-lock architecture is one of the worst possible foundations for SpacetimeDB's new pivot toward LLM and agentic-coding backends.

Why it matters

The review is a case study in a mistake it says recurs across the database market: newcomers assume raw performance numbers win customers, then build benchmarks that quietly compare products with different tradeoffs instead of stating those tradeoffs upfront. Its lasting value is technical: it explains exactly how SpacetimeDB gets its numbers, a single global mutex around an in-memory hash table, and why that design produces fast writes precisely by forbidding almost everything else from happening at the same time. That detail matters beyond one company's marketing, since SpacetimeDB is now pitching itself at LLM-driven, agentic-coding backends, a use case the review argues the same design fits particularly badly.

Who it affects

It affects engineers evaluating SpacetimeDB for a new backend, especially anyone drawn in by the version 2.0 benchmarks who is now building an LLM or agentic-coding application on top of it; teams already running multi-region, highly available distributed databases who might otherwise read the benchmarks as proof of a faster drop-in alternative; and SpacetimeDB itself, whose original design point, an MMORPG backend tolerant of losing tens of milliseconds of state, is being marketed to a very different, correctness-sensitive audience.

How to use it

Per the review, SpacetimeDB fits best where its original design point sits: a workload whose entire dataset comfortably fits in one machine's RAM, that tolerates eventually consistent replication and tens of milliseconds of durability lag, and that does not need to make HTTP calls from inside its core write path, since reducers cannot make them at all and the HTTP-capable Procedures feature is still in Beta. Scaling is vertical only, a bigger machine rather than more machines, since application code and data share the same instance. Teams that need synchronous, strongly consistent writes across machines, or that plan long or unpredictable operations inside a single transaction, should weigh the mutex and write-ahead-log details the review lays out before treating the version 2.0 benchmarks as representative of their own workload.

How solid is it

This is one systems engineer's blog post and technical opinion, not an independent audit; the review says outright that the author finds SpacetimeDB's marketing distasteful before attempting a fair assessment of the product itself. The core architectural claims, the mutex, the write-ahead-log interval, the reducer and view model, are backed with specifics rather than vague criticism, and the review points to a benchmark set on GitHub, published separately, that it says shows SpacetimeDB performing poorly against competitors, though it does not quote that set's numbers. Its central illustrative example, that PlanetScale's own extension could have been marketed as '10000 times faster than pgvector' on identical hardware, is explicitly a hypothetical about a claim PlanetScale chose never to publish, offered to explain why such comparisons mislead rather than as a report of SpacetimeDB's own results. The review carries a February 2026 dateline, roughly six months before this discussion surfaced it, with no indication in the source of why it resurfaced now.

Risks and caveats

The review does not name the specific competitor databases shown as 'the big losers' in SpacetimeDB's own benchmark chart, nor the numeric results from either SpacetimeDB's benchmarks or the alternate set it links to. It does not say whether SpacetimeDB has responded publicly to the critique, and its remarks on a possible SpacetimeDB v3 are explicitly speculation, not an announced roadmap. The whole piece is also one person's outside technical judgment; nothing in the source indicates the review's author has run SpacetimeDB in production.

“In 2026, if I were to launch a database product that is a hash table with a single lock in front of it, I'd do it quietly.”

— vmg, the review's author