netcup VPS 1000 G12 benchmarked: how fast is it really?

The VPS 1000 is netcup's entry-level VPS and the server most Serverküche recipes run on. But how fast is it really? We measured it thoroughly with standard tools – and show you the commands you can use to check your own server against it.

ℹ️ Note

The measurements were taken in July 2026 on a VPS 1000 G12. Since September 2026 netcup sells generation G12.5: same vCore and RAM configuration, but 128 GB SSD instead of 256 GB NVMe. The CPU, RAM and network figures below still give a good idea; for the disk figures you're better off re-measuring on a freshly ordered server – the commands are right here.

What are we building?

We benchmark the four things that matter in everyday self-hosting: CPU, memory, NVMe disk and network – each with established open-source tools (sysbench, fio, 7z, openssl, curl). All figures below come from a real VPS 1000 G12 on Debian 13. The test machine: AMD EPYC-Genoa, 4 vCore, 8 GB RAM, 256 GB NVMe.

The key figures at a glance (measured in July 2026 with sysbench 1.0.20 and fio 3.39 on a VPS 1000 G12 in netcup's Vienna data centre):

Quick assessment: for an entry-level VPS these are consistently strong figures – especially the NVMe disk and the network play well above what you'd expect from the cheapest plan. But the context matters: a VPS shares the physical CPU with other customers (shared vCores). Your figures can differ depending on the neighbors' load – how you spot that is in "When things go wrong".

Prerequisites

• A netcup server, e.g. your first VPS, with SSH access.
• The benchmark tools. All are in the Debian package sources:

  sudo apt update
  sudo apt install -y sysbench fio p7zip-full

• Some free storage space (the disk tests write a few GB temporarily) and ideally no production load during the measurement.

💡 Measure several times

A single benchmark is a momentary snapshot. Run each test two or three times and ideally at different times of day – then you see how stable the figures are.

Step by step

Step 1: Size up the server

Before you measure, look at what you're dealing with:

grep -m1 "model name" /proc/cpuinfo && nproc && free -h

model name : AMD EPYC-Genoa Processor
4
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       689Mi       3.0Gi       656Ki       4.3Gi       7.1Gi

Four vCores on an AMD EPYC-Genoa (G12, the generation current at the time of measuring) and 8 GB RAM. Also take a look at the steal time – the percentage the CPU "waits" because a neighbor on the same host is computing:

vmstat 1 3

In the st column (far right) it should ideally read 0. For us it was 0 over the whole test – no noticeable neighbor influence. High, persistent steal values would be the sign of an oversubscribed host.

Step 2: CPU

sysbench computes prime numbers – once on one core, once on all four:

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=4 run

1 Thread:   events per second:  1494.66
4 Threads:  events per second:  5973.69

Two things are remarkable here: the solid single-thread performance (Genoa cores are fast) and the almost perfect scaling – 4 threads deliver 3.996× a single one. That means: at the time of measurement, the four vCores were fully available, without neighbors siphoning off compute time.

A second, practical CPU test is the built-in 7-Zip benchmark (compression, uses all cores):

7z b

Tot:  ...  27425  (MIPS total)

7z b measures compression and decompression separately (each its own line) and combines both in the Tot: line into an overall rating – that's the roughly 27,400 MIPS. A good reference figure to compare the VPS with other 7-Zip results online. And because encryption runs everywhere (HTTPS, backups, VPN), the AES performance with hardware acceleration (AES-NI):

openssl speed -evp aes-256-gcm

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
AES-256-GCM      89283.37k   343370.05k  1270428.16k  3164995.93k  7671136.75k  8464845.66k

openssl speed measures single-threaded by default – so the figure applies to one core. For the throughput across all cores you append -multi $(nproc). In our run a single core reached about 7.7 GB/s (7,671,136 k) on the 8 KB blocks. TLS is thus never the bottleneck on this processor anyway.

Step 3: Memory

sysbench writes a large block repeatedly through RAM and measures the throughput:

sysbench memory --memory-block-size=1M --memory-total-size=30G --threads=4 run

30720.00 MiB transferred (28727.21 MiB/sec)

Around 30 GB/s – plenty for databases, caches (Redis/Valkey) and everything that keeps many small objects in memory. RAM on this plan is, in our experience, limited more by quantity (8 GB) than by throughput.

Step 4: NVMe disk

Here the wheat separates from the chaff – the disk is the actual bottleneck for most self-hosted apps. fio measures realistically when you bypass the page cache with --direct=1 (otherwise you measure RAM, not the disk). First the 4K random IOPS decisive for databases:

# Read (4K random read)
fio --name=rr --ioengine=libaio --direct=1 --rw=randread --bs=4k \
  --numjobs=4 --iodepth=32 --size=512M --runtime=20 --time_based --group_reporting

# Write (4K random write) – same command, only --rw=randwrite
fio --name=rw --ioengine=libaio --direct=1 --rw=randwrite --bs=4k \
  --numjobs=4 --iodepth=32 --size=512M --runtime=20 --time_based --group_reporting

read:  IOPS=101k, BW=394MiB/s
write: IOPS=67.0k, BW=262MiB/s

101,000 read and 67,000 write IOPS at 4K – that's real NVMe level and the reason why Nextcloud, databases or Paperless feel noticeably smooth on this VPS. And the sequential throughput (large files, backups, video):

# Read (sequential)
fio --name=sr --ioengine=libaio --direct=1 --rw=read --bs=1M \
  --numjobs=1 --iodepth=16 --size=2G --runtime=15 --time_based

# Write (sequential) – same command, only --rw=write
fio --name=sw --ioengine=libaio --direct=1 --rw=write --bs=1M \
  --numjobs=1 --iodepth=16 --size=2G --runtime=15 --time_based

READ:  bw=4123MiB/s (4.3 GB/s)
WRITE: bw=2937MiB/s (3.1 GB/s)

4.3 GB/s reading, 3.1 GB/s writing. A restic backup or a large docker pull is thus done in seconds.

Step 5: Network

For throughput, you download a large test file from a well-connected server. We take the Hetzner speed test in Falkenstein (Germany):

curl -o /dev/null -w "%{speed_download} B/s in %{time_total}s\n" \
  https://fsn1-speed.hetzner.com/1GB.bin

246095181 B/s in 4.36s

~246 MB/s, i.e. about 2 Gbit/s – 1 GB in just over four seconds. A download from the US (Ashburn) was, due to distance, at ~36 MB/s; within Europe the connection is excellent. Finally the latency:

ping -c 5 1.1.1.1

rtt min/avg/max/mdev = 12.314/12.337/12.365/0.019 ms

~12 ms to 1.1.1.1 (Cloudflare's Anycast resolver, i.e. a nearby network node – not a purely German target), very consistent (the deviation is in the hundredths). IPv6 is active and works; a ping over IPv6 was at ~26 ms.

When things go wrong

Your figures are well below ours, especially for the CPU. A VPS shares the physical CPU. Check the steal time (vmstat 1, column st) and top (line %st). If it's persistently high, neighbors on the same host are computing right now. Measure again at a different time of day – often the difference is gone then.

The disk figures are absurdly high (e.g. "10 GB/s random read"). You're missing --direct=1 – then fio measures the RAM cache, not the NVMe. Always test with direct I/O, otherwise the numbers are worthless.

lsblk shows ROTA=1 ("rotational") for vda in the column – is that a hard disk instead of NVMe? No. That's a virtualization artifact: the virtio driver reports the virtual disk as rotational across the board. The measured 100k+ IOPS and 4 GB/s prove that real flash storage is behind it.

The download is much slower than 2 Gbit/s. Measure against a nearby, fast server (e.g. Falkenstein). A distant target or a slow counterpart limits the measurement, not your VPS. A single curl stream also doesn't always exhaust the full bandwidth.

Every run delivers different numbers. Normal – benchmarks fluctuate. Measure multiple times, discard the first ("warm") run and take the median. Also compare only the same tool versions and parameters with each other.

Maintenance & backups

• Who is the VPS 1000 G12 enough for? For practically all the single services on this site – SSH, Traefik, Vaultwarden, Uptime Kuma, a small Nextcloud. It gets tight less at CPU or disk than at RAM: as soon as several heavy apps (Nextcloud + Immich + databases) run in parallel, an upgrade to the VPS 2000 (16 GB) is the most sensible next step.
• Watch steal time long-term. A one-off benchmark is a momentary snapshot. Whoever wants to keep an eye on performance long-term takes CPU steal, I/O and network into a Grafana dashboard – there you see creeping degradation before it hurts.
• Re-measure after changes. A server migration, a product switch or a new netcup generation changes the figures. Keep your benchmark outputs (a simple text file in the backup is enough), then you have a basis for comparison.
• Stay honest: benchmark numbers age and fluctuate. They're an orientation, not a promise – the shared vCores mean the real performance always also depends on the neighbors on the host. For the entry-level price, though, the VPS 1000 G12 delivers a remarkably well-rounded performance.

This post first appeared on serverkueche.de.