← Hacktakes · Edition 23
Hacktakes · Edition 23 · August 21, 2026

The Pangaea Architecture and other regressions

Merging compute and state into a single-threaded WASM database is a regression that abandons decades of concurrency progress to create a global bottleneck.

By Gus Barnaby

Sparked by SpacetimeDB: a short technical review · discussion

We eliminated travel time by putting the entire kitchen on this one cutting board.
“We eliminated travel time by putting the entire kitchen on this one cutting board.”

Mashing your entire application tier into a single-threaded WASM module inside a database is a violent biological regression triggered by a severe, industry-wide anxiety disorder.

I was sitting on the couch last night drinking cheap wine and eating stale Cheez-Its, actively ignoring the deeply unpleasant reading I need to do on modern caching topologies. I mean, I have to do it, but I don't want to do it. It's like going to the dentist, if the dentist charged you in AWS credits and lectured you about cache invalidation while drilling your molars. So instead, I found myself watching the Hacker News bloodbath over a phenomenally precise technical review of SpacetimeDB's pompous performance benchmarks.

The benchmarks look blistering if you don't look closely, and the Rust crowd is popping champagne because they think they've cured the database latency problem forever by shoving compute directly into the storage layer. They are completely ignoring the fact that they've essentially built a global bottleneck that turns every single concurrent request into a single-file line at the DMV. You take a wildly unscalable concurrency model, strip away all the network overhead so it spins in a tight local loop, and then proudly present the resulting illusion of speed as if you've just reinvented computing.

Let me back up. Because to understand why this is so insanely stupid, you have to understand how incredibly, astoundingly, spectacularly oblivious we all used to be about concurrency. I am a fat, washed-up dinosaur who has stared into more catastrophic Java threads than most junior developers will ever spawn in their entire careers.

Back in the late 90s, I was roped into auditing the source code for a buddy's mud—excuse me, a highly sophisticated text-based virtual reality simulation—where the original developer decided he was going to be the smartest guy in the room. This chump wrote the whole thing in Java 1.0. Sun Microsystems, in their infinite wisdom, had given us the infamous Vector class. The implementation strategy for Vector was purely to slap a synchronized keyword on every single method, creating a heavy-handed monitor lock that choked the life out of the program whenever two threads tried to simultaneously do anything.

This developer thought he was a genius. He had all these players running around the virtual world, and every time someone picked up a broadsword or dropped a piece of dragon scale, the code just locked the entire global game state. It deadlocked. It thrashed. It created phantom bottlenecks that made grown men weep into their keyboards. I remember spending four straight days debugging a situation where a player casting a fireball would cause the entire server to freeze for three seconds because the garbage collector was fighting the game-loop thread for the giant, monolithic state lock. It was a massive garbage fire, and the author was strutting around producing the architectural equivalent of a prolonged wet fart while his users disconnected in rage.

We spent two decades trying to undo that damage. Brilliant minds like Doug Lea came along and gave us java.util.concurrent, teaching us the arcane arts of lock-free data structures, Compare-And-Swap (CAS) operations, and the terrifying realities of the CPU cache-coherence MESI protocol. We learned, painfully, how to decouple things.

Which is why we are now witnessing the dawn of the Pangaea Architecture, famously marketed by SpacetimeDB as a database that is also a server, and folks, it is a bloody mess. For decades, our industry slowly evolved into distinct continents of compute and state, separated by vast oceans of network topology where you had to actually think about things like Byzantine fault tolerance and distributed lock management and the arcane magic of polymorphic inline caching. We had an Application tier continent, a caching continent, and a database continent. They all communicated across the water, creating a flourishing multi-cellular distributed ecosystem where different organs could scale entirely independently based on their metabolic needs.

But the continents got scared. The terrifying reality of eventual consistency gave the modern developer a collective panic attack. So what did they do? They violently crashed the continents back together into a single, massive, overflowing blob of state and compute with a giant padlock chained around it. We went from a thriving, parallelized organism right back to a single-celled, globally-locked amoeba.

Let's crack open the crust of this supercontinent and look at the molten core of how they are actually pulling this off. The payload here is WebAssembly, which has rapidly become the ultimate crack-pipe for developers who want to write backend logic without understanding how an operating system actually schedules work. The fundamental reality of WASM—which nobody on the internet apparently wants to admit out loud—is that it operates on a single contiguous block of linear memory.

Instead of blessing you with shared-memory concurrency, sophisticated thread-local storage, or fine-grained latches protecting the postorder traversal of your ASTs, WASM demands that you surrender to a massive, flat chunk of linear bytes. You have to lock this memory space down entirely every single time someone wants to mutate a single piece of dog poop in the persistence layer. So you have this colossal Pangaea amoeba swallowing every incoming transaction, and because it has to serialize all writes through a single master thread to avoid completely corrupting its own memory bounds, you are forcing a globally serial bottleneck on every mutation. You are quite literally building a toddler's toy chest with a titanium padlock clamped onto it.

Only one kid can play with a toy at a time. Every other kid in the room has to stand around screaming while the global lock is held. We have effectively reinvented dBase from the 1980s, just dressed up in a hipster Rust aesthetic. So go ahead, port your entire enterprise backend into a single-threaded WASM blob and tell me how 'fearless' your concurrency is when your whole app locks up to update a boolean. The comment section is open for the Rust zealots. Let the flames begin, etc. Yawn.

← Back to Edition 23