You’ve seen the hype cycle a hundred times. A new database launches, the benchmarks are astronomical, and suddenly every developer on your feed is ready to rewrite their entire stack. We want to believe in magic. But magic in software usually just means someone is hiding the tradeoffs.
When a database promises impossible performance, it’s not breaking the laws of physics—it’s just quietly breaking your application.
Enter SpacetimeDB. When it launched, the performance videos blew up. People assumed it was running on some proprietary, next-gen algorithms. Then you look under the hood, and as one early engineer casually admitted: the system is, well, a hash table with a lock in front of it. That’s it. That’s the secret sauce.
How do you get insane benchmark numbers? You strip away everything that makes a database safe for general use. You use a brutally simple data structure. You slap a coarse-grained lock on it. And, most dangerously, you run the application code directly inside the database server.
Benchmarks don’t measure how fast your system runs in production; they measure how fast it runs when it has absolutely nothing else to do.
The appeal of seeing through ‘impossible’ performance claims is realizing that the emperor has no clothes. SpacetimeDB isn’t magic—it’s a massive architectural gamble. Most applications cannot afford the tradeoffs it makes. If you run untrusted application code inside your database, you are one infinite loop away from a catastrophic crash. You are trusting application developers not to bring down the entire data layer. Good luck with that.
One of the core problems with running app code in the database is that you are forced to use the specific languages they prepared for you. Worse, you have to trust that the developers writing that code will never crash out, never leak memory, and never infinite loop. You are trading the safety of process isolation for raw, unadulterated speed.
In software, there are no magic tricks, only hidden costs waiting to be billed to your production environment.
We’ve all been burned by the ‘lies, damn lies, and database benchmarks’ trap. When you evaluate SpacetimeDB, don’t look at the benchmark numbers. Look at what happens when your code inevitably misbehaves. Next time a database claims it has solved the performance problem, ask yourself what corner they cut to get there. Because it’s never magic. It’s just a hash table with a lock.
FAQ
Q: What exactly is SpacetimeDB doing to get such high performance?
A: It relies on a simple hash table data structure with coarse-grained locking, and moves application logic directly inside the database process to eliminate network overhead. It's an architectural shortcut, not a breakthrough.
Q: Should I use SpacetimeDB for my next project?
A: Only if your workload perfectly matches their narrow tradeoffs. If you need complex queries, fine-grained concurrency, or isolation from potentially buggy application code, stay away.
Q: Is running app code inside the database actually a good idea?
A: It's a recipe for disaster for most teams. You're trading the safety of process isolation for raw speed, assuming your developers will never write an infinite loop or memory leak that brings down the entire data layer.