It's fun to daydream about scale. Of building huge systems that can hit the front page of Hacker News or weather the storm of Black Friday sales without breaking a sweat.

And we all enjoy benchmarks. Even if we don't blindly trust them, it's fun to hear that X is ten times faster than Y, and it's genuinely useful to know what kind of architectural choices made the difference. Scale is where we find out if we've solved the hard problems elegantly, in a way that really works. It's the pressure cooker that bad designs can't survive¹.

But let's be honest...I'm not Netflix and neither are you².

Recent benchmarks will tell you that Spacetime can do 300,000 transactions per second(!) My own load testing (personal project, modest hardware) comfortably did 100,000 TPS without any optimisation. Those are some incredible numbers.

But will my hobby projects ever need to handle that kind of load? Realistically, no. My side hustles will never get that popular, even in my wildest dreams.

What about the companies I've worked for? Well, most of the time it's a no there too. If your company needs to process 8 billion transactions a day³, you're in a club with 1% problems. Probably less. I don't know where the exact tipping point is for most people, maybe around 10k transactions per hour, but eventually your bottleneck isn't servers, it's marketing. You can't get enough users to create those kinds of problems.

So the big question arises: Do Spacetime's numbers actually matter in the real world? It scales, but does it need to scale?

My answer is yes. but only because scale has flipsides that we don't talk about enough. Flipsides that even small projects care about...

The Flipside of High Performance is Instant Performance

I once worked at a finance company where a busy day meant 10,000 transactions in an hour. That was a huge day. That was a "the CEO's buying champagne" day. Maybe the system ran a little slowly, but it was a massive win all-round.

For a company like that, being able to process 100,000 transactions in a single second isn't a scale issue. It's a responsiveness issue. It means that processing is so fast, every user's transaction is effectively instant. Even on your busiest days, as soon as your user's request hits the server it's basically already making the round trip back across the internet with the response. Processing happened in microseconds.

100,000 transactions per second doesn't mean you're planning to be as big as Amazon. It means you're able to build a service that's instant even on your busiest days. Sometimes performance isn't about what you can do at the absolute maximum. It's about making everyday load completely trivial.

The Flipside of High Capacity is Chilling Out

Another flipside - perhaps a more obvious one - is headroom. A system that's running at 25% capacity on a normal day is going to break on a busy one. If 25% load is business as usual, you need to start doing capacity planning now, because spikes are inevitable and that's probably not enough.

So no, maybe you don't need 100k TPS, but if you have it and you're running at 0.01% capacity, you can relax. You've got the headroom to handle a tsunami.

The Flipside of Scale Up is Scale Cheap

The last flipside is probably my favourite one, because I'm someone who puts lots of little experiments and fun hobby projects live. At work, my demands are high but my resources (roughly) match the task at hand. There's enough money to cover it. As a hobbyist, I just want whatever's cheapest.

From that point of view, scale becomes a rather fun financial argument. A system that can process 100k transactions and only bill me for one second of CPU is a system that can run my 100k transactions over the next three years and still only bill me for one second's worth of CPU. In principle I could pay for a second's worth of CPU and it might actually last me years.

Conclusion

When it comes to scale, "You Ain't Going To Need It" is generally good advice. The smart move is to focus on the right architecture for the problem at hand, and then reluctantly break that architecture when you eventually hit scale problems. But this is what's drawn me into Spacetime's orbit. There is no one-size-fits-all architecture, but the thing that comes closest is a transactional, relational database plus functions that modify it. That's Spacetime. Database plus functions, bundled into a neat package and optimised for modern hardware.

And that's the real point here. If Spacetime tied itself in architectural knots to get those performance numbers, then the scale might not be worth the effort. The fact that the performance comes as a consequence of simple, CPU-friendly architecture is what makes it compelling. You can write something simple and get the many upsides of performance for free. Even if You Ain't Gonna Need It, You Are Gonna Appreciate It.