Frankfurt is the default European location, and usually the right one: one of the world's largest internet exchanges, and no major capital in the west or centre of the continent more than about 25 ms away. The latency table, the workloads that fit, and the cases where another city wins.
A Frankfurt dedicated server is the default answer to "where in Europe should this go?", and most of the time the default is right. Frankfurt sits near the geographic middle of the European internet, hosts one of the largest internet exchanges in the world, and keeps your data inside Germany and the EU. But defaults get chosen by habit, and Frankfurt is also the most crowded hosting market on the continent. This piece covers who Frankfurt actually serves well, the latency it buys you, the workloads that suit it and the cases where another city would do better.
Three things made Frankfurt the centre of gravity, and all three still hold.
Interconnection. DE-CIX Frankfurt is one of the world's largest internet exchanges by peak traffic, and the city's data-centre cluster is where carriers, content networks and access providers from across Europe meet. For a server, what that buys is not a badge but short paths: traffic to a German, Austrian or Swiss home user can usually be handed to that user's provider without a detour through another country.
Geography. Draw a circle around Frankfurt and most of the EU's population falls within a short round trip. That is why it works as a single origin for a continent-wide audience.
Stability. Frankfurt is a financial centre and home to the European Central Bank. The data-centre market grew around customers who pay for redundancy, which shows in the power and carrier diversity of its facilities.
Light in fibre covers about 200 km per millisecond, so a round trip can never be shorter than the straight-line distance divided by 100. Real cable routes run longer than the straight line, so multiply by 1.3 to 1.5 and add a millisecond or two for routers:
| From Frankfurt to | Great-circle | Theoretical floor | Working estimate |
|---|---|---|---|
| Munich | 304 km | 3.0 ms | 5–7 ms |
| Zurich | 305 km | 3.0 ms | 5–7 ms |
| Amsterdam | 364 km | 3.6 ms | 6–7 ms |
| Berlin | 423 km | 4.2 ms | 7–8 ms |
| Paris | 478 km | 4.8 ms | 7–9 ms |
| Milan | 518 km | 5.2 ms | 8–10 ms |
| Vienna | 597 km | 6.0 ms | 9–11 ms |
| London | 638 km | 6.4 ms | 9–12 ms |
| Warsaw | 890 km | 8.9 ms | 13–15 ms |
| Stockholm | 1,187 km | 11.9 ms | 16–20 ms |
| Madrid | 1,445 km | 14.5 ms | 20–24 ms |
The pattern is the argument for Frankfurt: no major western or central European capital is more than about 25 ms away. A server here is never the best location for any single country outside Germany, but it is rarely a bad one for any of them. Choosing a server location explains the method behind these numbers and how to measure the real paths before you commit.
Add the last mile on top. A user on home broadband or a mobile network adds their own delay before the packet reaches the internet at all, and that part does not depend on where your server is.
A single origin for Europe. If you can run only one delivery server — for downloads, video or a CDN origin — Frankfurt minimises the worst case across the whole audience. The edges, if you add any later, can go where your analytics say users are waiting.
German-language services. Germany, Austria and German-speaking Switzerland together form one of Europe's largest online markets, and all three are within about 10 ms. For shops, SaaS products and media aimed at them, Frankfurt is the obvious home.
Live streaming ingest and delivery. Encoders across Europe reach Frankfurt over short, stable paths, and a central origin feeds restreamers or CDN pull zones in every direction. Streaming servers are built around this pattern; for a large live audience the origin's port is the number to size carefully, which is where a 25 Gbps dedicated server earns its place.
Data that must stay in Germany. Some contracts, public-sector customers and regulated industries require German hosting specifically, not just EU hosting. A Frankfurt server satisfies the letter of that requirement; EU data residency covers the parts of the requirement that a server's address does not settle, such as backups and who the contracting company is.
Your users are concentrated elsewhere. A Polish gaming community, a Romanian e-commerce site or a Spanish streaming service each lose 10 to 25 ms of every round trip by being served from Frankfurt. For interactive workloads, a server inside the target market wins outright.
Your users are outside Europe. Traffic from North Africa, the Middle East or Asia lands in Europe through southern cable stations, mostly in Marseille, and Frankfurt adds the distance from there. Users in North America are better served from the US east coast.
You need a second failure domain. Putting both your primary and your standby in the same metro protects you from a hardware fault but not from a regional power or network incident. Pair Frankfurt with Amsterdam for a short-distance pair, or with Bucharest or Warsaw for one that is genuinely far apart.
Because Frankfurt tends to host the central node — the one everything else pulls from — it is also where under-sizing hurts most. A useful exercise before ordering:
peak egress (Gbps) = peak concurrent users × average bitrate per user
Two thousand concurrent 1080p viewers at 5 Mbps each is 10 Gbps at peak. A download mirror serving 400 simultaneous clients at 25 Mbps each is also 10 Gbps. Size the port for that peak plus a margin, and remember that on an unmetered plan an idle gigabit costs the same as a busy one, so headroom is cheap compared with the cost of saturating during the event that matters.
Frankfurt is a free option at checkout, so it costs the same as any of our other 12 locations. Entry prices for the tiers that match the workloads above:
| Guaranteed bandwidth | Entry configuration | Per month |
|---|---|---|
| 1 Gbps unmetered | Dual Xeon E5-2630 v4, 20 cores, 128 GB | €209 |
| 10 Gbps unmetered | Dual Xeon E5-2630 v4, 20 cores, 128 GB | €659 |
| 25 Gbps unmetered | Dual Xeon Gold 6148, 40 cores, 256 GB | €1,799 |
Each tier also comes in larger builds, up to dual EPYC with 512 threads. Choose Frankfurt in the location selector on the tier's page; most in-stock builds are online within an hour of payment. The unmetered dedicated server buyer's guide compares all nine tiers by cost per delivered terabyte.
Before ordering, settle four things:
If the first answer puts most of your users in Germany, Austria, Switzerland or the Benelux, or spread evenly across the continent, Frankfurt is the right call and you can stop optimising.
For an audience spread across Europe, usually yes: no major capital in the west or centre of the continent is more than about 25 ms away. For an audience concentrated in one country outside Germany, a server inside that country will be faster.
No. A Frankfurt server starts at €209 a month with 1 Gbps guaranteed, the same as in our other 12 locations, because the city is a free option at checkout. What can differ is stock: a build on the shelf in one city may be assembled to order in another.
No single location does that. Hosting in Frankfurt keeps the primary copy of the data inside the EU, which is one part of compliance. Backups, monitoring, support access and your contracts with processors all need the same scrutiny.
The straight-line floor is about 6.4 ms round trip, and real paths usually land between 9 and 12 ms. Measure from where your users are before deciding; the figures here are planning estimates, not guarantees.
Unmetered says the bytes are not counted; it does not say the port is yours at the busy hour. The five contract clauses to check, how to size a tier from your peak, what each tier costs per delivered terabyte, and the 13 cities where the server can live at the same price.
Generating a token means reading the model's active weights once, so a CPU server's speed ceiling is its memory bandwidth divided by the model's size. The arithmetic, the catch in prompt processing, why two sockets are not twice as fast, and the workloads a big-memory EPYC box genuinely suits.
Most database performance problems are a working set that no longer fits in memory, or a commit that waits on a slow flush. How to measure both, how much RAM and what kind of disk to buy, where the CPU matters, and how to lay out replicas and backups.