Storage VPS vs regular VPS: what changes

Storage VPS vs regular VPS: the short answer

A storage VPS is a virtual private server sold by the terabyte, and a regular VPS is sold by the core. The storage plan gives you several terabytes of slow disk behind a small CPU share. The standard plan gives you a fast NVMe (non-volatile memory express) disk that is often twenty times smaller, plus more processor and more memory for the same money. Everything else about the two products matches: same hypervisor, same root shell, same Ubuntu image, same network stack.

That one difference decides the fit. A storage VPS is right for backup targets, media libraries, cold archives and anything you write once and read rarely. It is wrong for a database, or for any page a user sits and waits on, because those workloads need small random reads to finish in about a millisecond, and cheap capacity is cheap precisely because it cannot do that.

The plan names you meet on a pricing page

Four labels cover almost every provider, and only two of them mean something specific.

• Standard VPS. Two to eight vCPU, 2 GB to 32 GB of RAM, and 20 GB to 400 GB of NVMe or SATA SSD living on the host node itself.
• Storage VPS. 1 TB to 20 TB or more, usually spinning SATA disks or high capacity SATA SSDs, with one to four shared vCPU and a modest amount of RAM. It often costs the same per month as a small standard plan.
• VDS. Short for virtual dedicated server. There is no shared definition of this word, and the section below covers what to read instead.
• Block storage volume. Not a plan at all: a network attached disk you add to an existing VPS and pay for per GB per month. It is the only one of the four you can grow without moving the server.

Those ranges are the common shape across the market, not any one company's offer. The label on the plan is a category, so it tells you roughly which chassis your server lives on. It does not tell you the disk type, the CPU allocation policy or the bandwidth allowance, and those are the lines that decide whether your workload runs well.

What actually changes between the two plans

Disk type and quantity. This is the whole product difference. A standard plan puts you on NVMe flash reached over the PCI Express bus. A storage plan puts you on a large array of spinning disks or high capacity SATA SSDs. If you are unsure which of those words matters to you, start with what an SSD VPS is and how it differs from older disk plans and then the practical gap between NVMe and SATA SSD.

CPU ratio. Storage plans carry fewer vCPU per terabyte, and those vCPU are almost always shared with other tenants. That is not a flaw. A backup target spends its life waiting on the network, so it does not need cores.

RAM. Storage plans are RAM poor for their price. This bites in one specific place: filesystem metadata. Millions of small files need memory for the directory and inode cache, and without it every listing goes back to the disk.

Network allowance. Read this line carefully on a storage plan. Capacity you cannot restore from is not a backup. Check the monthly transfer allowance in TB and the port speed in Gbit/s, because a full restore of 4 TB over a 1 Gbit/s port takes about nine hours at line rate, and much longer if the port is shared.

[
  {
    "plan": "Storage VPS, HDD",
    "usd_per_tb_month": 3
  },
  {
    "plan": "Storage VPS, SATA SSD",
    "usd_per_tb_month": 9
  },
  {
    "plan": "Standard VPS, NVMe",
    "usd_per_tb_month": 40
  },
  {
    "plan": "Block storage add-on",
    "usd_per_tb_month": 90
  }
]

Those are rounded figures taken from public price pages across several providers in August 2026, not a quote from any single company, and they move. The shape is the part that lasts. A terabyte on a spinning storage plan costs around 3 US dollars a month. The same terabyte of NVMe on a standard plan costs about 40, and a network attached block volume is the most expensive of the 4 options at 90. For a wider view of what the monthly bill is made of, see what a VPS actually costs per month.

Why price per TB and price per core pull in opposite directions

A storage node is a chassis holding twelve to sixteen large disks with one modest processor in front of them. A compute node is the reverse: many cores, a lot of RAM, and two or four NVMe drives. The provider sells whatever that chassis has spare. So a plan that is cheap per terabyte is expensive per core, and a plan that is cheap per core is expensive per terabyte. There is no plan that is cheap at both, because no chassis is built that way.

This is why the honest answer to "which one should I buy" is often "both". A small NVMe VPS running the application, plus a storage VPS holding its backups, costs less than one machine large enough to do both jobs well. When one machine really must do both, you have left VPS territory: see when a dedicated server beats a VPS.

Random reads are what a cheap disk cannot do

[
  {
    "disk": "7200 rpm SATA HDD",
    "random_read_iops": "180",
    "typical_latency_ms": 8.5
  },
  {
    "disk": "SATA SSD",
    "random_read_iops": "75,000",
    "typical_latency_ms": 0.2
  },
  {
    "disk": "NVMe SSD",
    "random_read_iops": "600,000",
    "typical_latency_ms": 0.08
  }
]

Those are datasheet class figures rather than a benchmark of any provider. A 7200 rpm disk serves roughly 180 random 4k reads per second because the head has to physically move to the track and then wait for the platter to bring the sector under it, which costs about 8.5 ms every time. Flash has nothing to move, so a SATA SSD reaches about 75,000 and an NVMe device around 600,000 IOPS at 0.08 ms. That is a gap of more than three thousand times, and no amount of RAM or CPU closes it.

Sequential work is a completely different story, which is why storage plans are useful at all. A single spinning disk still streams 150 MB/s to 250 MB/s, and an array of them streams more. That saturates a 1 Gbit/s port, so a backup upload runs at full network speed and the disk is never the limit. Your figures also depend on how the array is built, since striping spreads one request across several disks: how RAID 10 changes storage plan performance covers that.

What does VDS mean?

Usually it is a marketing label. Three meanings are in common use, and the provider rarely says which one applies. Some use VDS for pinned or dedicated CPU cores, so no other tenant competes for your cycles. Some use it for full virtualization such as KVM, in contrast to container virtualization such as LXC or OpenVZ where you share the host kernel. Some use it for nothing at all beyond a name that sounds stronger than VPS.

You can settle part of it from inside the server. systemd-detect-virt prints kvm on a full virtual machine and lxc on a container, and a container means you cannot load kernel modules or run your own kernel. The dedicated CPU claim you have to measure, using the steal time check further down. Treat the letters on the plan as a hint, and the spec lines as the contract.

Which spec lines to check instead of the name

• The word printed next to the capacity: NVMe, SSD, SATA or HDD. If no disk word appears anywhere on the page, assume the cheapest hardware that fits the price.
• Whether the disk is local to the node or network attached. Network attached storage adds latency on every request and survives a node failure. Local disk is faster and dies with the node.
• The CPU wording: "dedicated" or "pinned" against "shared", "fair share" or nothing at all.
• Any IOPS or MB/s cap written into the plan. A cap of 500 IOPS makes the disk type almost irrelevant.
• Monthly transfer allowance and port speed, which set how long a full restore takes.
• Whether snapshots, backups and extra IP addresses are included or billed separately.

How to check the disk you actually got

Start with what the kernel reports, then stop trusting it.

lsblk -d -o NAME,ROTA,SIZE,MODEL
df -h /
nproc
free -h

ROTA is 1 for a rotational device and 0 for flash. Do not rely on it inside a VPS: a virtio disk usually reports ROTA=0 whatever sits behind it, because the hypervisor presents a generic block device and the guest never sees the physical drive. MODEL is empty for the same reason. The flag describes what the hypervisor declared, not what is spinning in the rack, so measure instead.

sudo apt update && sudo apt install -y fio
fio --name=randread --filename=/var/tmp/fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.test

--direct=1 bypasses the page cache, so you measure the disk rather than RAM. The line to read is read: IOPS=, with the distribution under clat percentiles (usec) below it. A standard NVMe plan reports tens of thousands of IOPS with a 99th percentile under one millisecond. A spinning storage plan reports a few hundred IOPS with a 99th percentile in double digit milliseconds. If fio reports that the libaio engine is not loadable, use --ioengine=psync --iodepth=1 and expect lower numbers, because that engine issues one request at a time.

vmstat 1 5
sudo apt install -y sysstat
iostat -x 1 5

In vmstat, the st column is steal time: the share of time your vCPU was ready to run while the host gave those cycles to another guest. A steady figure above 5 means the node is oversubscribed, which is the real test of a "dedicated CPU" claim. In iostat -x, watch %util, r_await and w_await. A %util near 100 with w_await in the tens of milliseconds means the disk is the bottleneck and no application tuning will help. For the flash specific checks, verifying that an NVMe disk is really NVMe goes deeper.

Pick by workload

• Backup target for restic, Borg or rsync. Storage VPS, and this is the case it was built for. Writes are large and sequential, deduplication happens on the source machine, and nothing is waiting on the result. One caveat: restic prune and restic check --read-data read the whole repository in small pieces, so budget hours for them and run them on a schedule. See running restic backups to a VPS.
• Immich or Jellyfin media library. Storage VPS for the files, with a warning about the CPU. Immich generates thumbnails and runs machine learning jobs on import, and Jellyfin transcodes on playback. Two shared vCPU will crawl through the first import of 200 GB of photos. Keep the database and the thumbnail cache on the fastest disk in the box. self-hosting Immich as a Google Photos replacement covers the sizing.
• PostgreSQL or MySQL. Standard NVMe plan. Every commit ends in an fsync that must reach durable storage before the transaction returns, so commit latency is disk latency, and an index lookup is a random 8 kB read of exactly the kind a spinning disk is worst at.
• Web application, API or control plane. Standard plan. These need cores and predictable latency, and they rarely need more than 100 GB.
• CI cache or artifact store. It depends on file size. Large tarballs stream from a storage plan at full network speed. A cache of hundreds of thousands of small files, pulled in parallel by several runners, is random IO in disguise and will disappoint you.

What it looks like when you get this wrong

The failure is never immediate. A database on a spinning storage plan feels fine with one user and collapses under ten, because queries that used to hit RAM start hitting the disk and each one now costs milliseconds instead of microseconds. Load average climbs while top shows the CPU mostly idle with a high %wa figure, which means processes are blocked waiting on the disk rather than computing anything. iostat -x 1 shows %util pinned near 100.

PostgreSQL says it plainly in its own log, since log_checkpoints is on by default from version 15:

LOG:  checkpoint complete: wrote 8241 buffers (2.5%); ... write=112.402 s, sync=9.318 s, total=121.914 s

The sync= figure is the one that matters. It is the time the checkpoint spent waiting for fsync to return, so a value in seconds means the disk cannot absorb writes as fast as the database produces them. Client connections stall during that window even though the query itself is cheap. The fix is not a configuration change. Move the data directory to NVMe, and keep the storage plan for what it is good at, holding the backups of that database.

FAQ

Is a storage VPS slower than a regular VPS?

For random reads and writes, yes, by a large margin. A spinning storage plan serves a few hundred small random requests per second at around 8 ms each, while an NVMe plan serves tens of thousands at well under 1 ms. For sequential transfers the two are much closer, because a storage array still streams 150 MB/s or more, which is enough to fill a 1 Gbit/s port. Measure your own with fio --rw=randread --bs=4k --direct=1 before you decide.

Can I run PostgreSQL on a storage VPS?

You can start it, and it will work until the working set no longer fits in RAM. After that every commit waits for an fsync on a slow disk, and Postgres logs it as a sync= figure in seconds inside checkpoint complete, while iostat -x 1 shows %util near 100 with high w_await. The usual arrangement is a small NVMe VPS for the database and a storage VPS as the target for its dumps.

Does VDS mean I get dedicated hardware?

Not reliably. VDS has no standard meaning. Some providers use it for pinned CPU cores, some for full KVM virtualization as opposed to a shared kernel container, and some use it purely as a name. Run systemd-detect-virt to see whether you are on kvm or lxc, and run vmstat 1 5 and watch the st column to see whether other tenants are taking your CPU cycles.

How do I tell whether my VPS disk is really NVMe?

Do not trust lsblk -d -o NAME,ROTA,MODEL, because a virtio disk normally reports ROTA=0 and an empty model string no matter what hardware is underneath. Run a 30 second fio random read test with --direct=1 and read the IOPS and the 99th percentile latency. Hundreds of IOPS at double digit milliseconds is a spinning array. Tens of thousands at under a millisecond is flash.