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.

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 (median of three runs each in October 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”.

How much they move is best seen over time. We re-measure the same server regularly and do not throw the old numbers away:

CPU and 7-Zip were 6 to 15% higher in July than today, while RAM throughput was lower. The disk and network figures are practically unchanged across every run. So take the values as an order of magnitude, not as a target your server has to hit.

Watch the “Method” row: the July values come from single runs, the later ones from the median of three. That is not a detail – 4K writes differ by more than a factor of three between the first run and the ones after it.

Prerequisites

• A netcup server, e.g. your first VPS, with SSH access.

• The benchmark tools. All are in the Debian package sources:

  Terminal

  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.

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       857Mi       4.4Gi       652Ki       2.8Gi       6.9Gi

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

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 0  0      0 4660104 245260 2666092    0    0     0     0  168  109  0  0 100  0  0  0

What matters is the st column in the cpu block – it should ideally read 0. Watch out that st is not the last column: the vmstat shipped with Debian 13 appends gu (guest time) on the right, and anyone blindly reading the last number reads the wrong one. For us st stayed at 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:  1390.13
4 Threads:  events per second:  5555.91

Two things are remarkable here: the solid single-thread performance (Genoa cores are fast) and the almost perfect scaling – 4 threads deliver 3.997× 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:             372   6295  23394

7z b measures compression and decompression separately and combines both in the last line. The three numbers there are CPU usage in percent, MIPS per busy core, and on the far right the overall rating – that’s the roughly 23,400 MIPS. A good reference figure to compare the VPS with other 7-Zip results online, but only against the same 7-Zip version: we’re measuring with 7-Zip 25.01 here, and a version change alone shifts the rating noticeably. 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      82218.15k   307847.98k  1179839.27k  2729521.15k  7034858.01k  7990618.79k

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.0 GB/s (7,034,858 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 (32043.47 MiB/sec)

Around 33 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).

mkdir -p /var/tmp/fiobench && cd /var/tmp/fiobench
findmnt --target . -no SOURCE,FSTYPE

/dev/vda4 ext4

Now 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=86.0k, BW=336MiB/s

101,000 read and 86,000 write IOPS at 4K – that’s real NVMe level and the reason why Nextcloud, databases or Paperless feel noticeably smooth on this VPS. The write figure is the most restless of the whole series, though: our very first run landed at just 27,600 IOPS, the three after it at 85,000 to 90,000. That’s exactly why you throw away the first run. 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=2392MiB/s (2.5 GB/s)

4.3 GB/s reading, 2.5 GB/s writing. A restic backup or a large docker pull is thus done in seconds. Clean up the test directory afterwards – depending on the run, fio leaves several GB behind:

cd / && rm -rf /var/tmp/fiobench

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

243470148 B/s in 4.410158s

~243 MB/s, i.e. about 2 Gbit/s – 1 GB in just over four seconds. The same test against Hetzner’s US location (ash-speed.hetzner.com, Ashburn) delivered only ~37 MB/s due to the distance and took 29 seconds; within Europe the connection is excellent. Finally the latency:

ping -c 5 1.1.1.1

rtt min/avg/max/mdev = 12.355/12.401/12.463/0.035 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: the same ping to 2606:4700:4700::1111 came back without packet loss. Comparing an IPv6 latency against the IPv4 figure isn’t worth much for an Anycast target, though – the two address families often land on completely different nodes.

When things go wrong

Your problem is not listed? Search all error messages →

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.