Storage VPS vs Regular VPS: Which One You Need
Storage VPS give you cheap terabytes but slower disk and less CPU. See the exact spec differences and which plan fits backups, archives, databases, or busy sites.
Storage VPS vs regular VPS: short answer
Storage VPS na virtual private server wey dem dey sell by terabyte, while regular VPS na core dem dey use sell am. Storage plan give you several terabytes of slow disk behind small CPU share. Standard plan give you fast NVMe (non-volatile memory express) disk wey often twenty times smaller, plus more processor and more memory for the same money. Everything else about the two products dey the same: same hypervisor, same root shell, same Ubuntu image, same network stack.
Na this one difference decide which one fit your need. Storage VPS good for backup targets, media libraries, cold archives, and anything wey you write once and read rarely. E no good for database, or any page wey user go sit down dey wait for, because those workloads need small random reads to finish in about one millisecond. Cheap capacity cheap because e no fit do that.
The plan names you go meet for pricing page
Four label dey cover almost every provider, but na only two get specific meaning.
- Standard VPS. Two to eight vCPU, 2 GB to 32 GB RAM, and 20 GB to 400 GB NVMe or SATA SSD wey dey for the host node itself.
- Storage VPS. 1 TB to 20 TB or more, normally spinning SATA disks or high-capacity SATA SSDs, with one to four shared vCPU and small amount of RAM. E often cost the same per month like small standard plan.
- VDS. Short form of virtual dedicated server. No shared definition dey for this word, and the section below explain wetin you suppose read instead.
- Block storage volume. E no be plan at all: na network-attached disk wey you add to existing VPS and pay for per GB per month. Na only this one among the four wey you fit grow without moving the server.
Those ranges na the common shape across the market, no be offer from any one company. The label for the plan na category, so e tell you roughly which chassis your server dey live on. E no tell you the disk type, CPU allocation policy, or bandwidth allowance. Na those lines dey decide whether your workload go run well.
Wetin actually change between the two plans
Disk type and quantity. Na this be the main product difference. Standard plan go put you for NVMe flash wey dey reach through PCI Express bus. Storage plan go put you for large array of spinning disks or high capacity SATA SSDs. If you no sure which of these terms matter to you, start with wetin SSD VPS be and how e different from older disk plans and then the practical difference between NVMe and SATA SSD.
CPU ratio. Storage plans get fewer vCPU per terabyte, and dem vCPU almost always dey shared with other tenants. This no be problem. Backup target dey spend most of e life waiting for network, so e no need many cores.
RAM. Storage plans get small RAM for their price. This dey cause problem for one particular area: filesystem metadata. Millions of small files need memory for directory and inode cache. Without enough memory, every listing go return to the disk.
Network allowance. Read this line well for storage plan. Capacity wey you no fit restore from no be backup. Check the monthly transfer allowance in TB and the port speed in Gbit/s, because full restore of 4 TB through 1 Gbit/s port dey take about nine hours at line rate, and e fit take much longer if dem dey share the port.
The data behind this chart
[
{
"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
}
]These na rounded figures wey dem collect from public price pages across several providers for August 2026. E no be quote from any one company, and the figures fit change. Na the general pattern go last. One terabyte for spinning storage plan dey cost around 3 US dollars per month. The same terabyte of NVMe for standard plan dey cost about 40, while network attached block volume na the most expensive of the 4 options at 90. For wider explanation of wetin make up the monthly bill, see how much VPS actually cost per month.
Wetin make price per TB and price per core dey pull for opposite directions
Storage node na chassis wey hold twelve to sixteen big disks, with one modest processor for front. Compute node na the opposite: many cores, plenty RAM, and two or four NVMe drives. Provider dey sell whatever spare capacity dey inside that chassis. So plan wey cheap per terabyte go cost more per core, while plan wey cheap per core go cost more per terabyte. No plan dey cheap for both, because no chassis dem build that way.
Na why the honest answer to “which one should I buy” often be “both”. Small NVMe VPS wey dey run the application, plus storage VPS wey dey hold its backups, go cost less than one machine wey big enough to handle both jobs well. If one machine really must handle both, you don comot from VPS territory: see when dedicated server dey better than VPS.
Random reads na wetin cheap disk no fit do
The data behind this chart
[
{
"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
}
]These figures come from datasheet class, no be benchmark for any provider. A 7200 rpm disk fit handle around 180 random 4k reads every second because the head must physically move go the track, then wait for the platter to bring the sector under am. This one costs about 8.5 ms each time. Flash no get anything wey need move, so SATA SSD fit reach about 75,000, while NVMe device fit reach around 600,000 IOPS for 0.08 ms. The difference pass three thousand times, and no amount of RAM or CPU fit close am.
Sequential work dey different completely, and na why storage plans useful at all. One spinning disk still fit stream 150 MB/s to 250 MB/s, and array of dem fit stream more. This one fit saturate 1 Gbit/s port, so backup upload go run at full network speed and disk no go be the limit. Your figures still depend on how dem build the array, because striping dey spread one request across several disks: how RAID 10 dey change storage plan performance cover that.
VDS mean wetin?
Most times, na marketing label. Three meanings dey common, and provider rarely talk which one dem mean. Some providers use VDS for pinned or dedicated CPU cores, so no other tenant dey compete for your CPU cycles. Some use am for full virtualization like KVM, unlike container virtualization like LXC or OpenVZ where una dey share the host kernel. Others no use am for anything beyond name wey sound stronger than VPS.
You fit confirm part of am from inside the server. systemd-detect-virt dey print kvm for full virtual machine, and lxc for container. Container mean say you no fit load kernel modules or run your own kernel. You need measure the dedicated CPU claim yourself, using the steal time check wey dey further down. Treat the letters for the plan as hint, and treat the specification lines as the contract.
Which spec lines to check instead of the name
- The word wey dem print next to the capacity:
NVMe,SSD,SATAorHDD. If no disk word dey anywhere for the page, assume say na the cheapest hardware wey fit the price. - Check whether the disk dey local to the node or na network attached. Network attached storage dey add latency for every request and e fit survive node failure. Local disk dey faster but e dey fail together with the node.
- The CPU wording: "dedicated" or "pinned" versus "shared", "fair share" or nothing at all.
- Any IOPS or MB/s cap wey dem write for the plan. Cap of 500 IOPS fit make disk type almost irrelevant.
- Monthly transfer allowance and port speed. Dem determine how long full restore go take.
- Check whether snapshots, backups and extra IP addresses dey included or dem dey bill am separately.
How to check the disk wey you really get
Start with wetin kernel report, then stop to trust am.
lsblk -d -o NAME,ROTA,SIZE,MODEL
df -h /
nproc
free -hROTA na 1 for rotational device and 0 for flash. No rely on am inside VPS: virtio disk usually report ROTA=0 no matter wetin dey behind am, because hypervisor dey present generic block device and guest no fit see the physical drive. MODEL empty for the same reason. The flag describe wetin hypervisor declare, no be wetin dey spin for 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 bypass page cache, so you dey measure disk instead of RAM. The line wey you need read na read: IOPS=, with the distribution under clat percentiles (usec) below am. Standard NVMe plan dey report tens of thousands of IOPS with 99th percentile under one millisecond. Spinning storage plan dey report few hundred IOPS with 99th percentile for double-digit milliseconds. If fio report say e no fit load libaio engine, use --ioengine=psync --iodepth=1 and expect lower numbers, because that engine dey issue one request at a time.
vmstat 1 5
sudo apt install -y sysstat
iostat -x 1 5For vmstat, st column na steal time: the share of time wey your vCPU ready to run while host give those cycles to another guest. Steady figure above 5 mean say node dey oversubscribed, and na the real test for "dedicated CPU" claim. For iostat -x, monitor %util, r_await and w_await. %util near 100 with w_await for tens of milliseconds mean say disk na the bottleneck, and no application tuning go help. For checks wey concern flash specifically, verify say NVMe disk really be NVMe go deeper.
Workload based pikin
- Backup target for restic, Borg or rsync. Storage VPS, and na this kind work dem build am for. Writes big and sequential, deduplication dey happen for source machine, and nothing dey wait for the result. One warning:
restic pruneandrestic check --read-datadey read the whole repository in small pieces, so give dem hours and run dem according to schedule. See how to run restic backups to a VPS. - Immich or Jellyfin media library. Storage VPS for the files, but make you watch the CPU. Immich dey generate thumbnails and run machine learning jobs when e import files, while Jellyfin dey transcode during playback. Two shared vCPU go move very slowly through the first import of 200 GB photos. Keep the database and thumbnail cache for the fastest disk inside the box. how to self-host Immich as replacement for Google Photos explain the sizing.
- PostgreSQL or MySQL. Standard NVMe plan. Every commit dey end with an
fsyncwey must reach durable storage before the transaction fit return, so commit latency na disk latency. Index lookup na random 8 kB read, exactly the kind read wey spinning disk dey handle worst. - Web application, API or control plane. Standard plan. Dem need CPU cores and predictable latency, and dem rarely need pass 100 GB.
- CI cache or artifact store. E depend on file size. Large tarballs dey stream from storage plan at full network speed. Cache wey get hundreds of thousands small files, and several runners dey pull dem in parallel, na random IO wey just disguise itself. E go disappoint you.
Wetin e look like when you get am wrong
The failure no dey happen immediately. Database for spinning storage plan fit look fine with one user, but e go collapse under ten users, because queries wey RAM dey handle before don start hit disk. Each query now dey cost milliseconds instead of microseconds. Load average dey rise while top dey show say CPU mostly idle with high %wa figure. This one mean say processes dey blocked as dem dey wait for disk, instead of dem dey compute anything. iostat -x 1 dey show %util pinned near 100.
PostgreSQL talk am clearly for its own log, because log_checkpoints dey enabled by default from version 15:
LOG: checkpoint complete: wrote 8241 buffers (2.5%); ... write=112.402 s, sync=9.318 s, total=121.914 sNa the sync= figure matter pass. E be the time wey checkpoint spend waiting for fsync to return. So, value for seconds mean say disk no fit absorb writes as fast as database dey produce dem. Client connections go stall during that period, even though the query itself cheap. Configuration change no be the solution. Move the data directory go NVMe, and keep the storage plan for wetin e good for: to hold the backups of that database.
FAQ
Storage VPS slower pass regular VPS?
For random reads and writes, yes, e slow well-well. Spinning storage plan fit handle only few hundred small random requests per second for around 8 ms each, while NVMe plan fit handle tens of thousands below 1 ms. For sequential transfers, the two dey closer, because storage array still fit stream 150 MB/s or more, and that dey enough to fill 1 Gbit/s port. Measure your own with fio --rw=randread --bs=4k --direct=1 before you decide.
I fit run PostgreSQL for storage VPS?
You fit start am, and e go work until working set no fit enter RAM again. After that, every commit dey wait for fsync for slow disk, and Postgres dey log am as sync= figure for seconds inside checkpoint complete, while iostat -x 1 dey show %util near 100 with high w_await. The usual arrangement na small NVMe VPS for the database, and storage VPS as the target for its dumps.
VDS mean say I get dedicated hardware?
No be always. VDS no get standard meaning. Some providers dey use am for pinned CPU cores, some for full KVM virtualization instead of shared kernel container, and some dey use am only as name. Run systemd-detect-virt to check whether you dey on kvm or lxc, then run vmstat 1 5 and monitor the st column to see whether other tenants dey use your CPU cycles.
How I go know whether my VPS disk really be NVMe?
No trust lsblk -d -o NAME,ROTA,MODEL, because virtio disk normally dey report ROTA=0 and empty model string, no matter the hardware wey dey underneath. Run 30 second fio random read test with --direct=1, then check the IOPS and 99th percentile latency. Hundreds of IOPS with double-digit milliseconds mean say na spinning array. Tens of thousands below one millisecond mean say na flash.