Frankfurt or Amsterdam: picking a European server location

Frankfurt and Amsterdam are about 450 km apart and both are first-tier European interconnection hubs. For the overwhelming majority of workloads the latency difference between them is a handful of milliseconds — smaller than the variation between two consumer ISPs in the same city. Which means the decision almost never gets made on latency, even though that is what everybody asks about first.

Here is what actually separates the two, how to measure the part that is measurable instead of guessing at it, and the three cases where the choice genuinely changes the outcome.

Measure it, do not estimate it

Every latency claim on a hosting site, this one included, is worth less than one measurement taken from where your users actually sit. Two rules make the measurement meaningful: test from the networks your traffic comes from, not from your own laptop on a fibre line, and test what your application does — a TLS request — rather than what ping does.

The measurement that matches what a browser feels

curl reports every phase of a request separately, which turns “the site feels slow” into a number you can act on. Put the format in a file once:

   dns:  %{time_namelookup}s
   tcp:  %{time_connect}s
   tls:  %{time_appconnect}s
  ttfb:  %{time_starttransfer}s
 total:  %{time_total}s
    ip:  %{remote_ip}

curl -w "@curl-format.txt" -o /dev/null -s https://your-test-host.example/

Read it as differences, not absolutes. time_connect minus time_namelookup is one network round trip and is the pure distance number. time_appconnect minus time_connect is the TLS handshake. Everything after that is your application, and if time_starttransfer is far beyond time_appconnect, the server location is not your problem — your code is.

Where the path actually goes

mtr --report --report-cycles 50 --tcp --port 443 -n your-test-host.example

--tcp --port 443 matters: many networks rate-limit or deprioritise ICMP, so a plain ping can show loss and jitter that your real traffic never experiences. Read the last line of the report for the latency that counts, and treat loss in the middle hops as noise unless it persists all the way to the end.

Measuring from somewhere that is not your desk

Your own connection tells you about your own connection. To see what users elsewhere get, use measurements taken from their side: RIPE Atlas gives you thousands of probes across European networks and costs nothing to run a one-off ping or traceroute from, and most transit providers publish a looking glass that will run a traceroute from their own routers towards your IP. Both are more honest than any latency map.

What a millisecond is actually worth

Round-trip time is not the wait — it is the unit the wait is counted in. A cold HTTPS request costs one round trip for the TCP handshake, roughly one more for the TLS handshake, and one more before the first byte of the response arrives. So a 20 ms RTT is closer to 60 ms of dead time before anything renders, and every uncached request that follows pays at least one more.

That multiplier is why the interesting question is not “how far is the server” but “how many round trips does one page cost”. An application that makes twelve sequential database queries against a database in another city has a location problem no data centre can fix. The same application with its database on the same machine does not care which city it is in.

For orientation, the bands this site’s own latency check uses: under 25 ms is excellent, under 60 ms is very good, under 120 ms is fine for anything that is not a game server. Frankfurt and Amsterdam are both comfortably inside the first band for most of Western Europe, from either city.

Where each city is genuinely different

• Frankfurt is the German interconnection hub and the centre of gravity for DACH traffic and much of Central and Eastern Europe. If your audience is German-speaking, or your customers’ procurement paperwork says the words “hosted in Germany”, this is the answer and the rest of the page is academic.
• Amsterdam is the Dutch hub, with a long-established density of international carriers and a traditional strength on routes towards the UK, the Nordics and across the Atlantic. It is also, on this site, the cheaper of the two.
• Both are among the largest exchange points in Europe, both are extremely well connected to each other, and neither is a compromise. The gap between Frankfurt and Amsterdam is far smaller than the gap between either of them and a cheap data centre in a city with one transit provider.

Jurisdiction, which is the real difference

Both countries are EU member states, so the GDPR, the Digital Services Act and EU consumer law apply identically in both. What differs is the national layer on top:

• Contracts and procurement. Plenty of German customers and public bodies require hosting in Germany specifically, as a clause rather than a technical need. If you sell into that market, Frankfurt removes an objection that no amount of measurement will.
• Content and takedown practice. Each country has its own national procedure layered over the EU rules, and hosts in each have their own established way of handling notices. If that matters to your project, read what DMCA-ignored hosting actually means before assuming a country choice does something it does not.
• Site obligations follow you, not the server. An imprint requirement or a consumer-law duty attaches to who you are and who you sell to. Moving a VPS across a border does not move those.

The price difference, stated plainly

On Standard KVM and Hi-CPU KVM, Frankfurt is the premium location and is charged as its own row rather than as a surcharge: every plan in the table carries both figures. The entry plan is €4.99 a month in Amsterdam and €6.99 in Frankfurt, and from the second rung upwards the German column sits about 20% above the Dutch one all the way up the ladder.

Same nine sizes, same hardware line, same network policy — you are paying for the location, and nothing else changes. That makes the decision unusually clean: if you cannot articulate a reason to be in Germany, Amsterdam is the same product for less.

Hardware is mostly not the tiebreaker

Standard KVM runs on Intel server CPUs with DDR4 ECC memory in both regions. Hi-CPU runs on AMD EPYC 7443 in both, and part of the German fleet is on the newer EPYC Genoa generation — which is what you may land on in Frankfurt, never something to hold us to per order. If a specific CPU generation is a requirement rather than a preference, a dedicated server is the product that can promise it; a shared virtualisation platform is not.

Three cases where the choice actually decides something

• Real-time workloads. Game servers, voice, trading, anything where a human or an algorithm feels the round trip. Here you put the server where the users are and measure it, rather than reasoning about it.
• Chatty multi-server architectures. App in one city, database in another, and every page multiplies the RTT by the number of sequential queries. Keep them together; if you must split them, split on an asynchronous boundary.
• Contractual data residency. When somebody’s compliance document names a country, that is the whole decision and there is no engineering argument to be had.

Everything else — marketing sites, WordPress, APIs behind a CDN, batch processing, build runners, backup targets — is genuinely indifferent between the two. Put a CDN in front of a static-heavy site and the origin’s city stops being visible to almost every visitor anyway.

Deciding in one minute

• German market, German paperwork, or an existing German footprint → Frankfurt.
• Everything else, and price is a factor → Amsterdam.
• Already running something in one of them → the same one. Co-location with your own database beats a few milliseconds of theoretical advantage every time.
• Genuinely unsure → take the cheaper one for a month and measure it from your users’ networks with the commands above. Moving later is a rebuild of one server, not a strategy.

When you do move, the DNS side is the part that bites: see pointing a domain at a VPS for records and TTLs, and moving a website from shared hosting to a VPS for the staged cutover that avoids downtime — the same procedure works unchanged when the move is between two of your own servers.

Frequently asked