The History of Expanso (Part 3): You Can't Change The Laws of Physics (Much)
The below is a continuation of the series on the history of Expanso. Today, we're talking about the three unchangeable laws of data - it's exponential growth, the speed of light, and global regulations. Read the whole series starting from Part 1.
The Three Unchangeable Laws of Data
Before we wrote the first line of code for Expanso, we reflected on the thousands of conversations we'd had with customers throughout our careers. Across teams in finance, manufacturing, logistics, and biotech, we heard the same story. New features were nice, but everyone was fighting a losing battle against a set of deep, structural problems that made their data infrastructure brittle and expensive.
A clear pattern emerged. These weren't problems you could solve by hiring more engineers or buying faster hardware. They were fundamental truths, as inescapable as gravity.
We realized that building a successful platform with Expanso meant we couldn't fight these laws. We had to build a system designed to obey them from the ground up.
Law #1: Data Growth is Exponential. Network Growth is Linear.
The first law is a brutal mismatch of curves. Every two years, the amount of data the world generates roughly doubles. But our ability to move that data doesn't. We can't double global network capacity every two years. One curve is a rocket ship; the other is a staircase.
This has turned the "big data" problem into a "moving data" problem. I saw company after company where the cost and complexity of shoveling petabytes from the edge to a central cloud were becoming unsustainable. Egress fees were no longer just a line item; they were a strategic liability. Data pipelines built on the assumption that you can just "move it all" are becoming slow, fragile, and punishingly expensive. You can't out-spend an exponential curve.
Law #2: The Speed of Light is a Hard Limit.
The second law is even more fundamental. Even with infinite bandwidth, you can't send a packet of data from a factory in Singapore to a data center in Ohio any faster than the speed of light allows. That round trip takes hundreds of milliseconds—for every bit!—and no amount of innovation will ever change that.
For a generation of applications, that latency didn't matter. But it's a non-starter for the world we live in now. You can't detect financial fraud after the transaction has already cleared. You can't shut down a faulty manufacturing line after the defective parts are in the box. Real-time AI, industrial automation, and critical infrastructure monitoring all require decisions to be made in milliseconds. When your business logic lives an ocean away from your data, you are physically incapable of operating in real time.
Law #3: Data Controls are a One-Way Street.
The third law isn't about physics, but it's just as immovable. Every year, the rules governing data get stricter. GDPR, CCPA, and national data sovereignty laws are just the beginning. At the same time, internal security and governance demands are rightly becoming more stringent.
Every time you copy data and move it across a border—or even a departmental boundary—you expand its attack surface and create a new compliance headache. You introduce new variables: Who has access? Is it encrypted correctly? Has its lineage been preserved? Centralizing data was once seen as a way to control it, but at today's scale, it has become a massive liability. It creates a single, high-value target for attackers and a nightmare for auditors.
You Can't Argue With Reality
These three laws have concrete consequences. They kill developer velocity, forcing teams to spend more time on data logistics than on building products. They strip you of control, locking you into a losing battle against latency, cost, and risk. And they create a massive bottleneck for the AI-native future, where models are starved for the fresh, real-world data they need to be effective.
We are at an inflection point. The only way to build reliable, secure, and fast systems in this new reality is to stop moving the data and start moving the compute.
In the next few posts, I'll dive into each of these laws in more detail. But first, I want to hear from you.
Which of these three laws is creating the most friction for your teams today?