← Blog

I moved my VPS from Hetzner (Germany) to Vultr (Singapore) — 280ms latency gone overnight

Hetzner CPX31 (4 vCPU AMD EPYC, 8GB) in Falkenstein is fast and dirt cheap — but 280ms RTT to Vietnam pushed TTFB to 1.2s. Moved to Vultr High Frequency AMD Singapore: $20 more per month, 60ms RTT, TTFB 280ms. Real benchmark + when region beats CPU price.

3 weeks ago I wrote a piece on picking a CPU for a VPS — conclusion: pick AMD EPYC because price/perf wins. True — but I skipped the variable that mattered more than CPU: datacenter location relative to your users.

My stack (Laravel + MySQL + Redis + Next.js, ~16 containers) ran on a Hetzner CPX31 in Falkenstein, Germany since January 2026. 4 vCPU EPYC Milan, 8GB RAM, NVMe — €15/month. CPU to spare, RAM to spare, disk fast. Perfect on paper.

Problem: 95% of my users are in Vietnam. RTT from Hanoi → Falkenstein is a steady 280ms (measured from 3 VN ISPs — Viettel, FPT, VNPT — at 8am, 2pm, 10pm). Every HTTPS request needs at least 1 TCP handshake + 1 TLS handshake + 1 HTTP round-trip — roughly 3× RTT = 840ms before the browser sees its first byte. Add Laravel’s TTFB of 200-400ms → total TTFB to browser: 1.1-1.4 seconds.

This week I migrated to Vultr High Frequency AMD in Singapore. Paid about $20/month more. RTT dropped to 60ms. This is the real benchmark and the lesson on when region beats CPU price.

The baseline — numbers before the move

Measured from 3 Hanoi clients (Viettel FTTH, FPT FTTH, 4G Viettel), curl against https://daivietpha.vn/healthz (a Laravel endpoint returning “ok”), 30 requests per client, median:

MetricHetzner FalkensteinMy target
Ping RTT (ICMP)278 ms<100 ms
TCP handshake280 ms
TLS handshake (TLS 1.3)290 ms (1-RTT)
TTFB (HTTPS)1,180 ms<500 ms
DOMContentLoaded (cold)2,400 ms<1 s
Lighthouse LCP (simulated VN 4G)3,800 ms<2.5 s

LCP at 3.8 seconds is deep red on Lighthouse. Google PageSpeed flags “Poor Core Web Vitals” — i.e. SEO penalty for Vietnamese users. For a landing page introducing daivietpha.vn (100% Vietnamese audience), that’s a deal-breaker, not an optimization.

CPU comparison — Hetzner vs Vultr Singapore

Since I’d already locked in AMD EPYC from the previous post, the real question was between regions.

Hetzner CPX31 (Falkenstein)Vultr HF AMD Singapore
vCPU4 (AMD EPYC Milan, shared)4 (AMD EPYC Genoa, shared HF)
RAM8 GB8 GB
Disk160 GB NVMe256 GB NVMe
Bandwidth20 TB5 TB
Price€15.90 (~$17)$48
Sysbench CPU (1 thread, prime 20k)8.2 s7.6 s (~8% faster)
Sysbench fileio rndrw 1G142 MB/s186 MB/s (~30% faster)
RTT from Hanoi278 ms62 ms

Vultr Singapore is actually faster on CPU and disk (because it’s Zen 4 Genoa, one generation newer than Hetzner CPX’s Zen 3 Milan). But that’s a detail. The real gap is RTT.

Roughly $30/month more. The 5TB bandwidth is plenty for a landing + API — I’ve never crossed 200GB/month. No bottleneck.

After the move — post-migration numbers

Same clients, same endpoint, same time-of-day:

MetricHetznerVultr SGImprovement
Ping RTT278 ms62 ms-78%
TLS handshake (1-RTT)290 ms70 ms-76%
TTFB (HTTPS)1,180 ms284 ms-76%
DOMContentLoaded (cold)2,400 ms720 ms-70%
Lighthouse LCP (VN 4G)3,800 ms1,650 ms-57%
PageSpeed Mobile Score (VN)4188+47 points

PageSpeed jumped Poor → Good purely because the datacenter is 220ms closer to the users. I did not optimize a single line of code.

Why RTT matters more than CPU for the web

Obvious in hindsight, but most devs (me included) skip it when comparing VPS plans. The reasons:

1. HTTPS needs round-trips to serve the first byte.

A normal HTTPS request needs at minimum:

  • 1 RTT for TCP SYN/SYN-ACK
  • 1 RTT for TLS 1.3 handshake (TLS 1.2 needs 2)
  • 1 RTT for HTTP request + first byte response

= 3 RTTs before the browser sees byte zero. At 280ms RTT → ~840ms of pure latency before the server even processes the request. Whether the server takes 50ms or 200ms to render is noise floating in the RTT ocean.

At 60ms RTT → 180ms RTT-overhead. A 200ms internal TTFB now accounts for 50% of total — and that’s the half you can actually optimize.

2. A CDN does not save dynamic content.

I used to think “stick Cloudflare in front of Hetzner, done.” Wrong. Cloudflare caches static assets (CSS/JS/images) well — but any request to /api/... or a server-rendered Laravel route still hits the origin. CDN bypass = 280ms RTT again. Đại Việt Phả is 80% dynamic (login, dashboard, family tree) and 20% static — CDN solves the 20%.

3. WebSockets + real-time hurt more.

I run a chat module inside the app. WebSocket latency = RTT. At 280ms → every message has a noticeable 280ms+ delay; it feels slow even when functionally correct. At 60ms → instantaneous feel. This isn’t a Lighthouse number — it’s user perception.

When to pick Hetzner (Germany) over Vultr Singapore

Don’t read this post and conclude “Vultr Singapore wins always.” It doesn’t. When Hetzner wins:

  • User base is in EU: inverse of my case. Users in France/Germany/UK → Hetzner crushes, Vultr Singapore is the bad option at 250ms RTT.
  • Workload is batch / background: a nightly cron job doesn’t care about RTT. Hetzner is 2-3× cheaper — take it.
  • Storage + bandwidth heavy: Hetzner gives 160GB NVMe + 20TB traffic for €16. Vultr equivalent ~$80. If your app serves heavy video / image galleries → Hetzner.
  • Staging / preview environments: latency doesn’t matter to devs. Hetzner.
  • Personal projects with no users: no users → no latency → Hetzner all day.

When to pick Vultr Singapore (or an Asia-region equivalent)

  • Main audience in Southeast Asia (VN, Thailand, Indonesia, PH, Malaysia): Singapore is a good centroid — RTT 30-80ms to most of these.
  • Consumer-facing, mobile-heavy app: mobile networks have jitter + retransmits; every extra RTT amplifies into 2-3× perceived slowness.
  • Real-time (chat, livestream, multiplayer): RTT is the metric.
  • SEO targeting a local market: Google measures Core Web Vitals from real Chrome users. Vietnamese users on Chrome → you need TTFB <600ms from VN → need a DC at <100ms RTT.

Singapore options across providers:

  • Vultr: HF AMD SG (what I’m on).
  • DigitalOcean: SGP1 region, Premium AMD.
  • Linode (Akamai): SG datacenter.
  • AWS: ap-southeast-1.
  • GCP: asia-southeast1.

I avoid Vietnam-domestic DCs (Viettel IDC, VNG Cloud, FPT Cloud): unclear software licensing policy, weaker English support, slower international peering for non-VN users. Singapore is the sweet spot.

Migration experience — 4 hours end-to-end

For anyone needing a playbook:

  1. Snapshot the Hetzner instance first — insurance. Hetzner charges €0.011/GB/month, a few cents.
  2. Spin up the new Vultr Singapore box — 5 minutes from click to SSH.
  3. Provision baseline: Ubuntu 24.04 LTS, Docker, docker-compose, ufw, fail2ban. I have Ansible, so this is 20 minutes.
  4. mysqldump on Hetznerscp to local machine → upload to Vultr. About 1.2GB compressed, 8 minutes total (going through local because Hetzner ↔ Vultr peering is poor; direct rsync between them took ~40 minutes in a test).
  5. Git clone the repo, docker compose up -d, restore MySQL, run any new migrations.
  6. Switch DNS — A record daivietpha.vn from Hetzner IP to Vultr IP. I dropped TTL to 300s two days earlier → DNS propagation completed in ~10 minutes.
  7. Watch Vultr logs for 30 minutes — no errors → power off Hetzner.
  8. After 7 quiet days → destroy Hetzner. Keep the snapshot for 30 days in case of rollback.

Total: 4 hours hands-on, downtime <2 minutes (DNS switchover).

Closing — region first, CPU second

The right VPS-selection order, per me:

  1. Identify where your users actually live → pick the datacenter region.
  2. Within that region, find providers offering AMD EPYC → pick the provider.
  3. Within that provider’s AMD line, size CPU + RAM + disk → pick the plan.

Most VPS-compare posts on Reddit/HN reverse this — they compare vCPU price first, then look at region. That’s right for globally-distributed SaaS (a product serving US + EU + Asia equally). It’s wrong for the 95% of freelance devs / small startups serving one local market.

Hetzner is still my favorite VPS on price. But if your audience is in Southeast Asia and you’re still on Hetzner EU — you’re paying a 1-second latency tax on every page load. That’s a steeper bill than the $30/month difference.

Sources

  • Hetzner Cloud pricing and datacenter locations: hetzner.com/cloud.
  • Vultr High Frequency AMD plan: vultr.com/products/high-frequency-compute.
  • TLS 1.3 1-RTT handshake reference: RFC 8446 §2.
  • Asia-Pacific peering quality reference: RIPE Atlas measurement IDs 78431201-78431203, April 2026.
  • PageSpeed Insights mobile benchmark via pagespeed.web.dev — slow 4G profile, Hanoi VN field data.