When Building a Database Beats Using One

Here's a sentence I never thought I'd write with a straight face: sometimes building your own database makes more sense than using Postgres.

I know. I've watched this story play out backwards a thousand times. Company decides existing solutions don't meet their needs. Company builds custom infrastructure. Company spends next five years maintaining that infrastructure instead of building their product. Company eventually migrates to boring technology. The End.

But Tyler Cloutier and his two-person team at Clockwork Labs started building an MMO called BitCraft Online—think Minecraft meets Runescape, with a fully editable persistent world—and ran into a problem that actually justified the nuclear option.

The Problem With Being Postgres

Cloutier's explanation of why Postgres doesn't work for real-time game state is the clearest articulation of database latency I've heard in years. He breaks transaction speeds into three scales: human scale (10 seconds), web server scale (10 milliseconds), and what he calls "spacetime scale" (100 nanoseconds to a microsecond).

Most web applications live comfortably in that middle zone. You query the database, do some logic, write back. One millisecond round trip to Postgres? Fine. Nobody notices.

But here's where the math gets interesting. If your transaction takes one millisecond and you're modifying the same piece of data—say, a monster's health that multiple players are hitting simultaneously—your theoretical maximum throughput is 1,000 transactions per second. Because during that millisecond, nobody else can modify that state.

"It's not even like the database is written very well," Cloutier explains. "It's just it was never going to work. There's a speed of light problem here and you need to do too much coordination."

They tried the standard approaches. Game server sends requests across the network to Postgres: doesn't work. Stored procedures in PL/SQL: technically possible but, as Cloutier puts it, "a huge pain." The permissions model doesn't work. Real-time synchronization doesn't exist. Every solution required building another layer of complexity on top.

The Nuclear Option

So they built SpacetimeDB. From scratch. In Rust. With a team of two.

Cloutier frames this not as gutsy but as inevitable: "For any MMO it's not as if you're just not going to need to build that stuff. You need to build it but it's not formalized as a database. So it becomes very complex very quickly and you end up having to solve more problems than otherwise."

He's not wrong about MMO infrastructure becoming a nightmare. He mentions talking to people who worked on Amazon's New World—50 teams, each with their own microservices. That's the path you go down when you try to bolt real-time game state onto traditional database architecture.

SpacetimeDB's core insight is eliminating interactive transactions—those long-running transactions where you can begin, wait, query, wait again, then eventually commit or rollback. Traditional databases need multi-version concurrency control (MVCC) to handle this without everything grinding to a halt.

SpacetimeDB says: we don't do that. Every transaction gets the whole database state, completes extremely quickly, and exits. The tradeoff is you can't hold a transaction open for 10 seconds while you contemplate your database choices. But what you gain is speed.

How much speed? Their benchmarks claim 4,000 transactions per second with Node and Postgres, 104,000 with SpacetimeDB, and 167,000 if you write your reducers in Rust.

The Architecture of Fast

Two technical decisions drive most of that performance gain.

First: they run backend logic inside the database process, not across the network on separate web servers. This eliminates the network hop that most developers treat as the cost of doing business. "In spacetime DB it's embedded directly in the database in the same process," Cloutier says. "So just the roundtrip time of talking to the database is extremely low."

Second: thread-per-core architecture. They pin each thread to a specific hardware core instead of letting the OS scheduler move it around. Why? CPU cache levels.

L1 cache is 10 to 100 times faster to access than L3 cache. But L3 is the first cache level shared by all cores. If the OS keeps moving your thread between cores, you're constantly flushing L1 and hitting L3. For a database that needs to touch the same data repeatedly—like that monster health we keep decrementing—keeping everything in L1 matters enormously.

They even abandoned Tokio for database execution, using it only for the outer HTTP layer. Tokio is built for workloads where each job is unrelated to the previous one. SpacetimeDB's workload is the opposite—tons of correlation between consecutive operations.

The Questions That Remain

The performance numbers are impressive. The technical reasoning is sound. But I'm left with the usual questions that arise when someone builds their own database.

First, the benchmark optimizes for a specific workload—many small transactions hitting the same piece of state. That's exactly what a game server needs. It's less clear whether this architecture generalizes to other use cases that might justify the marketing reach SpacetimeDB is attempting.

Second, they've explicitly punted on interactive transactions for now. Cloutier says they could add it later, but the whole design philosophy is "never compromise on the ability" to do those high-frequency state modifications. Adding MVCC later means either accepting performance degradation or maintaining two execution paths.

Third, there's the criticism Cloutier himself mentions: "We have a post from Vicente Marti and he says in summary, it's not a very good database and it is a big marketing miss." I haven't dug into that critique, but it's worth noting that people who build databases for a living are skeptical.

The interesting part isn't whether SpacetimeDB becomes the next Postgres. It's whether Cloutier's framing holds: that building a specialized database was actually less risky than trying to make traditional architecture work for their specific problem.

They're now a 35-person company. The database is a separate product. Investors asked about it before they even planned to release it. BitCraft Online is available on Steam.

Maybe this time really is different. Or maybe we're watching the first act of a story I've seen before. The only honest answer is: check back in five years.

—Mike Sullivan, Technology Correspondent