How to Choose a VPS Server Location: Latency, Data Residency and Jurisdiction

Published 27 October 2026

Server location is usually presented as a dropdown. It is really three decisions wearing one label: how far the machine is from the people using it, which legal system the data sits under, and which catalogue options are available there at all. Getting one of those right and the others wrong is how projects end up migrating six months later.

This guide separates the three, gives a way to reason about latency without guessing, and then describes the six sites this catalogue actually sells — Amsterdam, Zurich, Singapore, Miami, Bucharest and Chisinau — including what each is and is not good for.

The three questions behind the dropdown

Performance. Distance sets a floor on round-trip time that no amount of bandwidth can lower. If your application makes five sequential round trips to render a page, geography multiplies into user-visible delay.

Residency. Where the bytes physically sit. If you handle personal data, this may be a legal requirement rather than a preference, and it applies to backups and snapshots too, not just the live disk.

Jurisdiction. Whose courts and regulators can reach the operator. A server in Zurich is not operated under EU law merely because it is 600 km from Brussels.

A fourth, quieter question is availability: not every product is sold at every site. Dedicated servers are offered in five of the six, GPU servers in four, Windows RDP in five and shared hosting in four, and Chisinau carries VPS only. The VPS catalogue shows the matrix live for each category.

Latency, without the marketing

Light in optical fibre travels at roughly 200,000 km per second, about two-thirds of the speed of light in vacuum. Because a round trip goes out and back, the absolute floor is about ten microseconds per kilometre of path. Real networks add routing, switching, congestion and — often the largest term — the detour between the straight line and the actual fibre route.

That gives useful lower bounds:

Amsterdam to Zurich — about 620 km, floor around 6 ms. Real-world round trips are typically in the low teens.
Amsterdam to Bucharest — about 1,800 km, floor around 18 ms. Expect roughly 30–40 ms in practice.
Miami to New York — about 1,750 km, floor around 17 ms. Expect 25–35 ms.
Miami to São Paulo — about 6,500 km, floor around 65 ms. Expect 110–130 ms.
Singapore to Sydney — about 6,300 km, floor around 63 ms. Expect 90–110 ms.
London to Singapore — about 10,850 km, floor around 110 ms. Expect 160–180 ms.

Those are order-of-magnitude numbers to reason with, not measurements of any particular route. The point is the shape: intra-Europe is a few milliseconds to a few tens, transatlantic is tens, and anything crossing to Asia–Pacific is well over a hundred. You cannot optimise that away by buying a bigger plan.

What latency actually costs an application

One round trip is rarely the problem. The problem is how many you need:

Static content behind a CDN — the origin location barely matters for the first byte to the user, because the CDN edge answers. It matters for cache misses and for anything dynamic.
A typical dynamic page — TLS handshake, request, database query, response. Each stage that crosses the network adds a round trip; five of them at 170 ms is nearly a second of pure waiting.
SSH and remote desktops — latency is felt directly as input lag. A Windows RDP session from Europe to Singapore is workable for reading mail and unpleasant for anything interactive.
Batch work — video encoding, model training, nightly ETL. Location is irrelevant to the result; only price and hardware matter.
Database replication — cross-region writes pay the round trip twice, once for the commit and once for the acknowledgement.

How to measure before you commit

Do not trust a latency table, including this one. Measure:

From where your users are. A ping from your laptop in Berlin says nothing about users in São Paulo. Use a looking-glass service, an uptime monitor with probes in several regions, or a cheap test server in each candidate site.
With mtr, not just ping. ping gives you the average; mtr --report shows where the losses and the extra hops are, which is usually more actionable.
At the hour your users are active. A route that is 30 ms at 04:00 can be 60 ms at 20:00.
With real traffic, not ICMP. Many networks deprioritise ICMP. curl -w "%{time_connect} %{time_starttransfer}" against a file on the candidate server is closer to what a browser experiences.

If the answer is "our users are everywhere", that is an argument for a CDN and possibly two small servers rather than one large one in the middle.

Residency: the data, not the brand

Data residency is a statement about where storage sits. Three details usually decide whether a location is compliant with whatever rule applies to you:

Backups and snapshots. Frequently stored in a different country from the primary disk, and rarely mentioned on the pricing page. Ask.
Replication and disaster recovery. A second copy in another region is good engineering and a residency problem if nobody planned for it.
Support access. Who can read the disk, from where, and under what agreement.

The sites here are labelled with their jurisdiction — EU and GDPR for Amsterdam and Bucharest, Swiss FADP for Zurich, Singapore PDPA, US state law for Miami, Moldovan national law for Chisinau. Those labels describe the legal environment, not a legal conclusion about your project. Whether a transfer of personal data from your country to that site is lawful is a question for your own analysis, and for a lawyer if the answer matters commercially.

Jurisdiction: whose court, not whose continent

A useful exercise is to ask, for each candidate site: if someone wanted the contents of this server, what would they have to do?

In an EU member state the answer involves a court order or a production order under EU or national law, a supervisory authority with enforcement powers, and the GDPR's rules on transfers out of the bloc. In Switzerland it involves Swiss procedural law, which is a different framework with different timelines. In Singapore the PDPA governs handling but disclosure obligations come from separate criminal and civil process. In the United States, state and federal process both exist and subpoenas are routine. In Moldova the framework is national law, and the practical answer depends on the operator's establishment rather than the rack.

None of that is a guarantee in either direction, and none of it should be read as advice. The useful part is the discipline of asking, because a provider that cannot say which legal entity operates the service and where it is established cannot answer any of the rest.

The six sites, honestly described

Amsterdam, Netherlands. EU member state, GDPR applies, one of the best-connected metros in Europe with dense peering to the rest of the continent and to transatlantic routes. The default choice for European users on latency grounds. VPS from 14 USD per month; the full VPS range and dedicated, RDP, GPU and hosting are all sold here.

Zurich, Switzerland. Outside the EU, Swiss FADP, excellent connectivity into Central Europe and northern Italy. The choice when the requirement is European latency with a non-EU jurisdiction. VPS from 18 USD per month, and the full product range is available.

Singapore. The Asia–Pacific site: PDPA applies and round-trip times to South-East Asia are excellent, to Australia good, and to Europe around 170 ms. VPS from 16 USD per month, with dedicated, RDP and GPU available; shared hosting is not sold here.

Miami, United States. US state law, strong routes into Latin America and the US east coast. VPS from 13 USD per month, with every product category available.

Bucharest, Romania. EU member state with GDPR, noticeably cheaper per core than Western Europe, and well peered into Central and Eastern Europe. VPS from 11 USD per month, with dedicated, RDP and hosting available; GPU servers are not sold here.

Chisinau, Moldova. Moldovan national law, the entry price point, and provisioned to order rather than from standing stock. VPS from 10 USD per month, and VPS only.

A decision recipe

Map the users. Where are the majority, and where is the latency-sensitive minority? For most projects it is one region plus a long tail.
Shortlist two sites on residency and jurisdiction, not on price.
Measure both from two or three real locations with mtr and an HTTP timing, at a realistic hour.
Check the category matrix. If you need a GPU server and are set on Chisinau, the site's answer is Bucharest or Amsterdam instead.
Check the price at the configuration you actually need, not the entry rate. A 2 vCPU baseline and an 8 vCPU/32 GB build are different purchasing decisions.
Write down why you chose, so a migration in two years starts from a reason rather than a guess.

Mistakes worth avoiding

Choosing by price alone. The cheapest site is a good deal only if latency and residency are acceptable; otherwise it is a future migration with a deadline attached.
Treating "EU" as one place. Amsterdam and Bucharest share a legal regime and are 1,800 km apart. Both facts matter.
Forgetting backups. A compliant primary with backups in the wrong country is a residency failure with extra steps.
Assuming one server serves the world. Above roughly 100 ms to a significant user group, a CDN or a second small server usually beats a bigger machine.
Confusing hosting location with company location. The operator's establishment decides who can be compelled; the rack decides where the bytes are.
Never re-measuring. Latency changes as networks are re-routed, and user distribution changes faster than most teams notice.

If you are still weighing the type of machine rather than its location, VPS vs dedicated server covers the hardware side, and what offshore hosting actually changes covers the jurisdictional one. The dedicated server catalogue is the other place to compare sites directly, since those offers are priced per location. Every server here is prepared manually after payment review, so a location that is right the first time saves more than a support ticket.