The Geography of Milliseconds

01 / The Map Is Not the TerritoryWhat distance actually costs

The naive view of internet geography is that you rent a server where your users are. West Coast US app? Deploy to us-west-2. European customers? Use Frankfurt. This is the hyperscaler model, and it is optimized for one thing: getting the last five milliseconds off a page load.

That optimization comes at a premium. AWS's us-east-1 is the most expensive compute region on the planet because it serves the largest concentration of latency-sensitive traffic on earth. Every millisecond matters in Manhattan, so Manhattan-adjacent compute commands Manhattan-adjacent pricing.

But here is the thing that changes everything: the map of what a millisecond costs is not the same as the map of what compute costs.A cycle in Frankfurt costs roughly the same as a cycle in São Paulo if you are buying from the same provider. But a cycle from a hyperscaler in any region costs 3–5x a cycle from a smaller provider in that same building.

02 / The Latency ArbitrageWhy 80ms is the new zero

Here is the realization that unlocked this for me. My personal applications are not trading platforms. They are not real-time multiplayer games. They are not voice or video. They are things like: a blog, an agent orchestrator, a file server, a build runner, a background job queue. Every single one of them works fine at 80ms round-trip. Most work fine at 200ms.

The user does not notice 80ms. The page loads. The API responds. The job completes. The only people who care about sub-20ms latency are high-frequency traders, live event streaming platforms, and multiplayer shooter games. That is a set of use cases. It is not the universe.

Once you accept that 80ms is fine, the effective map of the earth shrinks to the radius of anything within ~3000 miles of a major peering point. That opens up a lot of territory.

The table is not perfectly precise — prices fluctuate, bandwidth costs differ, and Hetzner's ARM offering is even cheaper. But the shape is real. A vCPU in Helsinki costs a fifth of what it costs in Virginia. The latency penalty for a US-based user is roughly 100ms.

03 / The Infrastructure StackHow to build around geography

The objection is always the same: "But what about egress costs? What about network reliability? What about latency for dynamic content?"

These are real concerns. They are also solvable.

Egress. Hetzner charges ~1€/TB for outbound traffic beyond 20TB. AWS charges ~$0.09/GB. That is a 45x difference. If your application is bandwidth-heavy, the egress savings alone can justify the latency trade. And if you are serving static content, Cloudflare or Bunny CDN in front of a foreign origin solves the last-mile problem entirely.

Network reliability. Hetzner's Nuremberg and Helsinki data centers have better peering with the US east coast than most people realize. I have run production workloads on a $10/mo Hetzner box for three months. Zero downtime. Full SSH session latency of ~100ms — noticeable, but not prohibitive for anything except interactive terminal work.

Dynamic content. If your app has a database behind it, the limiting factor is rarely the network hop. It is the query time. An API that takes 50ms to compute and returns 10KB of JSON does not care whether the server is 30ms or 120ms away. The request takes 160ms instead of 80ms. The user does not notice.

04 / The Market That Is OpeningLatency compression as a trade liberalizer

There is a deeper structural shift here that goes beyond personal hosting choices. The compression of latency is acting as a form of trade liberalization for the compute market.

Historically, distance created friction in the following way: the further a server was from its users, the higher the latency, and the worse the experience. That friction acted as a natural tariff wall, protecting local providers from foreign competition. If you were building an app for US users, you had to use US data centers. If you were in Europe, you used European ones. The market was naturally balkanized.

What has changed is not the physics of light through fiber. It is the tolerance budget of modern applications. As applications have shifted from real-time interactivity to asynchronous, agent-driven, and batch-oriented architectures, the latency budget has expanded. A Slack notification can arrive 200ms late without anyone caring. An AI agent's response can take two seconds. A CI/CD pipeline trigger can wait five seconds.

The result is a genuinely global compute market for the first time. A solo developer in Austin can provision VMs in Helsinki, run databases in Nuremberg, and cache through Cloudflare edges in 330 cities — and pay less than the cost of a single AWS t3.medium in us-east-1. The effective price of compute is converging globally because the latency penalty for buying from a distant provider is converging on zero for an increasingly large class of workloads.

05 / The Real ConstraintEgress and regulatory lock-in

If latency is the first-order constraint that is weakening, egress pricing and data residency regulation are the second-order constraints that are only starting to bend.

Egress. The incumbents charge egress margins that are purely rent-seeking. AWS egress is ~$0.09/GB. Hetzner is ~$0.001/GB. The difference is not a cost difference — it is a switching cost. The hyperscalers know that once your data is in their S3 bucket, moving it costs more than keeping it there. The European Data Act is beginning to chip away at this by mandating data portability and fair pricing. But as of 2026, egress still represents the most effective lock-in mechanism in the industry.

Regulatory lock-in. GDPR, data sovereignty requirements, and financial services regulations all create artificial boundaries in the compute market. If your data must stay in the EU, you cannot buy compute in South Africa, even if it is cheaper. These constraints are real and will not disappear. But they are bounded — they create boundaries, not a general restriction on global arbitrage.

The practical reality for most solo developers and small teams is that regulatory constraints are a non-issue. Your user data is wherever you put it. Your application code does not care about GDPR residency unless you are processing PII in a specific jurisdiction. For the personal projects, side hacks, and small SaaS apps that drive most innovation on the internet, these constraints do not apply.

06 / The Personal CalculationWhat I run, where, and why

Here is the concrete personal setup that made me write this post, because the theory matters less than the monthly bill.

The equivalent stack on AWS in us-east-1, with comparable specs (not comparable — AWS instance types are not 1:1 with Hetzner dedicated hardware), would run somewhere around $350–$500/mo. RDS alone for a similarly provisioned Postgres instance would be $150–$200. The savings are not 20%. They are 80–87%.

What do I give up? About 100ms of round-trip latency. The first time you SSH into a server in Finland from Texas, you feel the pause. After the second time, you stop noticing. The page loads, the API responds, the database queries run, and everything works. The only time I notice is when I am running interactive CLI operations — but I do that rarely enough that it is a non-issue.

07 / The OpportunityThe global compute market is still fragmented

The most interesting implication of this shift is not the personal savings. It is the market structure. The global compute market is still heavily fragmented along geographic lines. Most developers provision in the closest data center to themselves or their users, even when that choice costs 4x more than an equivalent resource a few thousand miles away.

That fragmentation is an arbitrage opportunity for anyone willing to build around it. Companies like Hetzner, OVH, Scaleway, and Leaseweb are competing on price in regions where the hyperscalers have not bothered to compete, because the hyperscalers are selling latency, not compute. When the customer stops caring about the latency, the premium evaporates.

The infrastructure is in place. Undersea cables are abundant. Peering is cheap. CDNs have solved the last mile. What remains is a cognitive bias — the assumption that your server should be near your users. For an increasingly large class of applications, that assumption is false.

The geography of milliseconds is not the geography of kilometers. It is the geography of attention — what you are willing to notice, and what you are willing to pay to not notice it. Once you stop noticing the pause, you stop paying the premium. And that changes everything.