Low-Latency VPS in the USA (2026): Who Has a Datacenter Near Your Users, and How to Measure It Yourself

How this page ranks, and what it refuses to claim

The table is ordered by the number of US metros in which a provider sells a VPS, on the reasoning that more sites means a better chance of one near your users, and that a provider with sites on both coasts and in the centre lets a national service place servers where they are needed. Locations come from the provider's own region API or location page; the source is named in each row. The page does not rank on latency, because it has no latency measurements to rank on and would not trust a single set if it did: a figure measured from one city at one hour describes one path at one hour. Where a provider labels a site by a region rather than a city (Vultr's "Silicon Valley", Linode's "Fremont", OVHcloud's "Vint Hill"), the label is kept.

US datacenters per provider

Two notes on the counts. Linode's ten regions include two in Washington DC (us-iad and us-iad-2), so its metro count is nine. DigitalOcean's regional availability page lists six US regions but sells standard Droplets in five, with Atlanta, Richmond and Kansas City marked for Premium CPUs only and Memphis carrying only v5 and GPU Droplets; a buyer of the $12 Basic Droplet has New York and San Francisco. The hyperscalers are outside the table because they are not priced per plan: Google Cloud has nine US regions, Azure nine, Oracle four (Ashburn, Phoenix, San Jose, Chicago) and Lightsail three; their reviews list them.

Which metro serves which users

The table is geography, not measurement: it says who is close, not how close in milliseconds. Distances inside a metro are irrelevant; distances across the country are not; and routing between two nearby cities can occasionally go the long way round, which is exactly what the measurement section is for. The datacenter guide and the city pages (Seattle, San Francisco, Chicago, Atlanta, Miami) go city by city.

A national audience: central, or two servers and a CDN

If your users are spread across the country, no single site is close to all of them, and there are two workable strategies. One server in the centre, Dallas or Chicago being the sites most providers share, keeps the worst case moderate for both coasts. Or two servers, one east and one west, with a CDN in front for static content and either DNS steering or an application that can run in two places for the dynamic part; that is more work and doubles the server bill, which at InterServer's $3 or Vultr's $10 is not much. A CDN alone, in front of one server anywhere, fixes the static part of the page for everyone and is the cheapest latency improvement most sites can make, because the static part is usually most of the bytes. The dynamic part still travels to the server, and for that the server's location is the lever.

Measuring it yourself

The only latency number that describes your situation is one measured from where your users are to the site you are considering. Three ways to get it.

1. Provider test endpoints. Several providers run public hosts in each datacenter for exactly this. Linode publishes speedtest hosts per region (speedtest.newark.linode.com, speedtest.fremont.linode.com, speedtest.dallas.linode.com, speedtest.atlanta.linode.com and others on the same pattern). InterServer's speed test page offers test files from its Secaucus, Los Angeles and Dallas servers. Kamatera's data centers page has a latency test button for each city, including its seven US sites. Hostwinds's datacenter page has latency test buttons for Seattle and Dallas. Vultr's and DigitalOcean's test hosts did not respond to this site's tools and are not listed. Against any endpoint that answers ICMP:

# round-trip time, 20 samples, from the machine you run this on
ping -c 20 speedtest.dallas.linode.com
# the route and per-hop timing, which shows where the time goes
mtr -rwc 50 speedtest.dallas.linode.com

2. From your users, not from you. Run those commands from the cities that matter: a colleague, a customer, a rented desktop in that city, or a monitoring service with probes there. Your own connection tells you about your own city.

3. From inside a one-hour server. On Vultr, Linode, DigitalOcean, Kamatera, Lightsail or Hetzner, create the smallest server in each candidate region, and from it ping the addresses your application will talk to (your database, your users' ISP resolvers, your CDN). Destroy it after. The cost is a few cents per region and the result is the one you will actually live with.

Whatever you measure, measure more than once, at different hours and on different days; a single reading is one path at one moment.

What else moves latency besides distance

• Routing. Two networks may exchange traffic in a city far from both endpoints. mtr shows it; a different provider in the same metro can take a different route.
• TLS and connection setup. Each new connection costs round trips before the first byte; HTTP/2, keep-alive and TLS session resumption cut the number of round trips, which matters more than shaving a few from each.
• The server itself. A slow query adds more to a page's time than a hundred miles does. Latency is only the floor.
• The database's location. An application that makes many database calls per request needs the database on the same host or in the same datacenter; a managed database in another region multiplies its distance by the number of calls.
• Burstable CPU. On Azure B-series, EC2 T instances and Lightsail, a VM out of credits answers slowly for reasons that have nothing to do with the network.

What this page could not verify

• Any latency figure between any city and any datacenter: none measured, none quoted.
• Vultr's and DigitalOcean's per-region test hosts: their site pages did not load for this site's tools; Vultr's regions are from its API and DigitalOcean's from its documentation.
• RackNerd's full location list: its KVM page lists the eight cities above and its navigation adds Utah; only the eight are counted.
• Whether any provider sells an anycast IP product: not read; no claim made.
• Facility-level detail (which building, which carriers): the providers' own network pages, where they publish it.