Netcup vs Hetzner (2026): Dedicated EPYC Root Servers vs Hetzner Cloud Architecture

Why AMD EPYC 9645 (Zen 5) Matters for Database & Vector Workloads

For workloads that rely on SIMD vectorization—such as pgvector HNSW index builds in PostgreSQL, ClickHouse columnar aggregations, cryptographic hashing, or quantized ONNX inference—the native 512-bit AVX-512 execution units on EPYC 9645 prevent the frequency downclocking historically seen on Intel Xeon scalable processors and double the per-cycle vector throughput of Zen 4’s double-pumped 256-bit implementation.

Furthermore, because Netcup Root Servers guarantee dedicated cores rather than burstable credits, sustained 100% CPU utilization during nightly pg_dump compression, Rust/Go CI/CD builds, or media encoding does not deplete a token bucket or trigger hypervisor throttling.

• ▪ Netcup RS G12.5 Host CPU: AMD EPYC 9645 (Turin, Zen 5, 4nm process, native 512-bit AVX-512, DDR5-6000 memory controllers).
• ▪ Netcup VPS G12.5 Host CPU: Shared AMD EPYC vCores with fair-share CFS quotas—excellent for I/O-bound nginx/PHP-FPM/Node.js workers where average CPU load stays under 30%.
• ▪ Hetzner Cloud Shared (CX / CPX / CAX): CX uses cost-optimized Intel/AMD shared vCPUs; CPX uses shared AMD EPYC vCPUs; CAX uses Ampere Altra Arm64 cores.
• ▪ Hetzner Cloud Dedicated (CCX): Dedicated AMD EPYC vCPUs (primarily Milan/Genoa pools depending on availability zone) with zero steal time, priced at a significant premium for hourly flexibility.

Auditing Your Node’s CPU Flags, Cache Topology & Steal Time

When validating a newly provisioned KVM instance in Nuremberg or Falkenstein, inspecting /proc/cpuinfo and lscpu reveals how the hypervisor configures QEMU CPU model pass-through (host-passthrough vs generic virtual CPU definitions) and whether L3 cache boundaries align with a single AMD EPYC Core Complex Die (CCD). On a pinned EPYC 9645 Zen 5 node, keeping all four threads of an RS 1000 G12.5 inside the same CCD preserves 32 MB of shared L3 victim cache locality and prevents cross-socket Infinity Fabric latency.

Run the read-only diagnostic commands below immediately after provisioning a Netcup or Hetzner instance to verify exposed CPUID instruction flags, L2/L3 cache topology, and real-time hypervisor steal metrics during peak European business hours.

# 1. Verify exposed CPU model, sockets, cores, and L3 cache pass-through
lscpu | grep -E "Model name|Socket|Thread|NUMA|L2|L3|Flags"

# 2. Check specifically for Zen 5 / AVX-512 instruction set extensions
grep -o -E 'avx512f|avx512dq|avx512bw|avx512vl|avx512_vnni|avx512_bf16' /proc/cpuinfo | sort -u

# 3. Sample hypervisor steal time (%steal) across all vCPUs at 1-second intervals
# On a dedicated Netcup RS or Hetzner CCX node, %steal should remain 0.00-0.10%
mpstat -P ALL 1 5

Architecture:             x86_64
Model name:               AMD EPYC 9645 96-Core Processor
avx512_bf16
avx512_vnni
avx512bw
avx512dq
avx512f
avx512vl
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Average:     all    4.12    0.00    0.85    0.05    0.00    0.10    0.00    0.00    0.00   94.88

Netcup Traffic Flatrate (>3 TB / >2 TB per 24h Shaped) vs Hetzner’s 20 TB (EU) / 1 TB (US & SG) Quotas

Netcup provisions a dedicated virtual port speed of 2.5 Gbit/s across both its Root Server G12.5 plans and its VPS 500–8000 G12.5 plans (with 1 Gbit/s on entry-level VPS pico/nano G11.5s instances). Outbound and inbound traffic is unmetered under Netcup’s transparent traffic flatrate policy: on Root Server G12.5 plans, if rolling 24-hour transfer exceeds 3 TB, port speed is temporarily shaped to 300 Mbit/s; on VPS 500–8000 G12.5 plans, if rolling 24-hour transfer exceeds 2 TB, port speed is temporarily shaped to 200 Mbit/s (and automatically restored once the 24h window drops below the threshold) rather than generating a surprise per-terabyte overage invoice.

Hetzner Cloud attaches instances to a 10 Gbit/s shared host interface, which permits rapid short-duration bursts when pulling container images inside the same datacenter. However, Hetzner enforces hard monthly outbound traffic caps: 20 TB in EU locations (Nuremberg, Falkenstein, Helsinki) and only 1 TB to 2 TB on entry-to-mid tiers in US (Ashburn/Hillsboro) and Singapore, billing roughly €1.00/TB (EU) or significantly more in APAC/US for every additional terabyte.

• ▪ Predictable Billing Shield: On Netcup, an unexpected viral traffic spike or an unmitigated L7 scraper cannot cause a four-figure bandwidth overage bill—at worst, port speed steps down until traffic normalizes.
• ▪ US & Singapore Advantage: Deploying a Netcup RS 1000 G12.5 in Manassas (US-East) or Singapore gives you the same unmetered fair-use traffic model as Nuremberg, whereas Hetzner’s Singapore and US Cloud tiers restrict base traffic to 1–2 TB.
• ▪ IPv6 Architecture: Both Netcup and Hetzner assign a routed /64 IPv6 subnet alongside a static /32 IPv4 address. Netcup’s SCP panel allows granular reverse DNS (PTR) delegation per individual IPv6 address—essential for self-hosted SMTP mail relays (Postfix/Mailcow).

Workload-Specific Selection Rules

When partitioning services across your infrastructure budget, evaluate each workload by its duty cycle (24/7 baseline vs ephemeral burst), storage synchronization sensitivity (fdatasync tail latency vs live-migration requirements), and reliance on proprietary cloud SDN primitives:

• ▪ Deploy on Netcup RS 500 / RS 1000 G12.5 (€10.86–€18.26/mo net | €12.93–€21.73/mo gross) when: You need 2 to 4 dedicated AMD EPYC Zen 5 cores for PostgreSQL/MySQL, Redis, Docker Compose/Coolify monoliths, Mailcow, or 24/7 Kubernetes baseline worker nodes.
• ▪ Deploy on Netcup VPS 1000–8000 G12.5 (€12.18–€56.39/mo net | €14.50–€67.11/mo gross) when: You need high ECC RAM per euro (8 GB to 64 GB) with SSD storage and a 2.5 Gbit/s port for memory-heavy caching, Java/Spring Boot heaps, or low-CPU web clusters.
• ▪ Deploy on Hetzner Cloud (CX/CAX/CPX/CCX) when: You auto-scale ephemeral Kubernetes nodes via Karpenter/Cluster Autoscaler, require managed L7 Cloud Load Balancers, or need hourly billing for short-lived environments.
• ▪ Deploy a Multi-ASN Hybrid (AS197540 + AS24940) when: You want carrier-diverse DNS/Anycast frontends or off-site streaming database replicas separated across two independent German autonomous systems.

Live Migration Blueprint: Hetzner Cloud to Netcup Root Server

When migrating a live production workload from Hetzner Cloud to a Netcup RS 1000 G12.5, establish an encrypted WireGuard point-to-point tunnel (10.99.0.1/30 to 10.99.0.2/30) with an explicit MTU = 1420 (or 1360 if encapsulation traverses a Hetzner vSwitch with a 1400-byte MTU ceiling). This allows your database logical replication and two-pass rsync synchronization to run over a private interface before flipping public DNS records:

# Step 1: Lower DNS TTL to 60 seconds at least 24 hours prior to maintenance window

# Step 2: Run Pass-1 online bulk rsync over WireGuard (10.99.0.1 = Hetzner, 10.99.0.2 = Netcup)
rsync -aHAXxv --numeric-ids --info=progress2 \
  -e "ssh -T -c aes128-gcm@openssh.com -o Compression=no" \
  /var/lib/docker/volumes/ root@10.99.0.2:/var/lib/docker/volumes/

# Step 3: Put application in maintenance mode, flush WAL, and stream compressed pg_dump directly
pg_dump -Fc -Z 6 -d production_db | ssh root@10.99.0.2 "pg_restore -d production_db --clean --if-exists -j 4"

# Step 4: Run Pass-2 final delta rsync (completes in seconds) and update A/AAAA DNS records
rsync -aHAXxv --delete --numeric-ids /var/lib/docker/volumes/ root@10.99.0.2:/var/lib/docker/volumes/