What is an SSD VPS? Flash storage explained

What is an SSD VPS?

An SSD VPS is a virtual private server whose disk is backed by flash memory instead of a spinning hard disk. SSD stands for solid state drive: storage built from NAND flash chips, with no moving parts inside. VPS stands for virtual private server: one isolated slice of a physical host machine, running its own operating system, sold to you as if it were a whole server. Put the two together and the label promises one thing. When your server reads a block of data, nothing mechanical has to move first.

That is the whole definition. Everything below is about what the label leaves out, because the words "SSD hosting" on a pricing page say very little about the storage array behind them.

If you are still working out how a VPS differs from a plain virtual machine, the difference between a VPS, a VM and a VPC is the better page to read first.

Why hosts advertise storage speed instead of storage size

A plan page lists CPU cores, memory, disk size and bandwidth, and then adds one word about the disk that is not a size at all. Hosts do that because capacity stopped being the interesting number about storage years ago. The two numbers that decide how a server feels are IOPS (input/output operations per second) and latency (how long one operation takes to come back).

The mechanical difference is the reason. A hard disk keeps data on rotating platters and reads it with a head on a moving arm. To reach a block somewhere else on the platter, the arm has to seek, and then the disk has to turn until the right sector arrives under the head. At 7200 revolutions per minute, half a turn averages about 4 ms, and the seek adds several more. Flash has no arm and no platter, so a read is an electrical lookup that returns in tens of microseconds.

[
  {
    "device": "7200 rpm hard disk",
    "random_read_iops": "125",
    "read_latency_ms": 8
  },
  {
    "device": "SATA SSD",
    "random_read_iops": "90,000",
    "read_latency_ms": 0.15
  },
  {
    "device": "NVMe SSD",
    "random_read_iops": "600,000",
    "read_latency_ms": 0.08
  }
]

A 7200 rpm hard disk is rated for roughly 125 random 4k reads per second, and one of those reads takes about 8 ms to come back. An NVMe drive is rated near 600,000 of the same reads, at about 0.08 ms each. The SATA SSD between them is rated near 90,000. Read those as orders of magnitude, not as a percentage improvement.

Two warnings about that data. These are published specifications for whole drives of each class, so they are manufacturer sheet figures and not something measured on a VPS. And you never get a whole drive: your volume is a share of one device, or a share of an array, sitting next to other customers on the same hardware.

The two columns also answer different questions, so read them together. Latency is how long you wait for one operation. IOPS is how many operations the drive can work on at the same time. Flash reaches its high IOPS figures through parallelism, because many flash chips answer many requests at once while a deep queue keeps them busy. A single threaded program that issues one read, waits for it, then issues the next will never see the top of that chart. It sees the latency column instead.

SSD, NVMe, SATA and PCIe: four words at four different layers

Buyers confuse these words because each one describes a different part of the system.

• SSD is the medium. It means the data sits on NAND flash chips rather than on magnetic platters.
• SATA is an interface, designed in the era of mechanical disks. It tops out at 6 Gbit/s, which is around 550 MB/s of real throughput, and its command queue holds 32 outstanding commands.
• NVMe (non-volatile memory express) is a protocol written specifically for flash. It supports many queues holding thousands of commands each, so several CPU cores can talk to the drive at the same time without sharing one narrow queue.
• PCIe (peripheral component interconnect express) is the bus NVMe runs over, the same kind of lanes a graphics card plugs into.

So a SATA SSD and an NVMe SSD both store data on flash. They differ in the interface they speak. A SATA SSD is still far quicker than any hard disk, but that 32 command queue limits how much parallel work it can express, and parallel work is exactly what flash is good at. Which one is worth paying for depends on your workload, and the NVMe versus SATA SSD decision takes that apart properly.

Local flash or network attached storage?

Two very different arrangements are sold under the same word.

Local storage means the flash drives sit inside the same physical host as your VPS. A request travels over PCIe inside one machine and comes straight back, which is how the latency stays in the tens of microseconds.

Network attached storage means your virtual disk lives on a separate storage cluster, often Ceph or a SAN (storage area network), and every read and write crosses a network to reach it. Providers usually call this "cloud block storage" or "elastic volumes". The flash is real. The network trip is real too, and it is added to every single operation, so latency lands in the high hundreds of microseconds or the low milliseconds instead of the tens.

Neither is the wrong answer. Network storage survives the death of a host, because the data was never on that host: the provider can start your server on other hardware and the disk follows it. Local NVMe is faster and is tied to one physical machine, so a hardware failure there means a restore from backup. Ask which one a plan uses. Almost nobody does.

What the difference feels like on a real server

Server work is mostly small random reads and writes, not long sequential transfers. That is why the MB/s figure in the marketing copy is the least useful number on the page.

• Database commits. A database that promises durability calls fsync when a transaction commits, then waits for the drive to confirm the data is really stored. On a hard disk that wait is milliseconds, which holds a small database to the low hundreds of commits per second. On flash the same wait is a fraction of a millisecond. This is where the gap is widest, whether you run PostgreSQL, MySQL or SQLite as a production database.
• Package installs. apt install unpacks thousands of small files and syncs them to disk as it goes. Almost none of that work is sequential, so it is bound by IOPS.
• Container image pulls. docker pull fetches compressed layers over the network and then extracts them into thousands of small files. The download is network bound. The extraction is disk bound, and on a slow volume the extraction is the part you sit and wait for.
• Boot and reboot. Startup reads a kernel and an initramfs, then hundreds of small unit files and shared libraries scattered across the volume.

None of that is a large sequential read. A volume that streams 500 MB/s while serving only 3,000 IOPS will still feel slow during a docker compose pull, because the wait is counted per file, not per megabyte.

Why "SSD cloud hosting" on a pricing page tells you almost nothing

The word describes the medium and stops there. It says nothing about the interface the drive speaks, and nothing about whether that drive is in the same machine as your server. It also says nothing about the ceiling your plan is allowed to reach.

That ceiling matters most and it is advertised least. Providers cap IOPS and throughput per volume, because one host serves many customers and an uncapped neighbour can starve the rest. A cap of a few thousand IOPS on hardware capable of hundreds of thousands is normal and honest, and it is invisible in the plan description. Two plans can both say "SSD" while one is local NVMe with no per volume cap and the other is a shared cluster volume limited to 3,000 IOPS.

Caps come in two shapes. A sustained cap is a flat ceiling that never moves. A burst cap gives you a low baseline plus credits that let you exceed it for a while, and those credits refill while the volume is idle. A burst cap looks excellent in a five minute test and then drops to the baseline in the middle of a database import or a large restore. If a provider quotes a large number, ask how long you are allowed to hold it.

How to check what your VPS actually gave you

From inside the guest you can only see what the hypervisor tells you.

lsblk -d -o NAME,ROTA,MODEL,SIZE
cat /sys/block/vda/queue/rotational

Replace vda with the device name lsblk printed for your disk. ROTA and the rotational file read 0 when the kernel has been told the device is non-rotational, and 1 when it has been told the opposite. A virtual disk sets that flag from what the hypervisor advertises, so it describes the virtual device and not the physical hardware underneath it. MODEL is usually empty for a virtio disk such as vda, or a generic string such as QEMU HARDDISK on an emulated SATA controller. Guests are not meant to see the host's array, and they do not.

So treat the flag as a hint and measure the rest. Run a random 4k test with fio against a file on the volume, at the queue depth your application really uses, and run it long enough to use up any burst credit. Benchmarking a VPS properly has the fio commands and the common mistakes that produce flattering numbers.

Three questions to ask a provider before you buy

1. Is the storage local to the hypervisor, or is it network attached? The answer sets the floor on your latency, and it decides what happens to your data when a physical host fails. A provider who answers this plainly has thought about it.
2. What is the IOPS limit on my volume? Ask for a number. "Unlimited" and "enterprise grade" are not numbers. If there really is no cap, ask what stops a neighbour on the same host from taking the whole array during their backup window.
3. Is that limit sustained or burst? If it bursts, ask for the baseline and the length of the burst. The baseline is the figure your nightly job will live with, so it is the one to plan around.

Does flash wear out, and is that your problem?

Flash cells accept a limited number of write cycles, so drives publish an endurance rating in TBW (terabytes written) or DWPD (drive writes per day). The drive spreads writes evenly across its cells, which is called wear levelling, and it holds spare blocks in reserve to replace cells that fail. On a VPS the wear is the provider's problem: they watch the SMART counters on their own drives and replace hardware before the rating runs out. Your problem is older than flash. A drive is not a backup, and redundancy under your volume is not a backup either, because it copies a deletion as faithfully as it copies data.

The trade you are really making is price per gigabyte. Flash costs more per gigabyte than spinning disks, so an SSD plan usually sells less capacity than a hard disk plan at the same price. If you need bulk space for media or archives, keep the fast volume small and put the bulk somewhere cheaper, which is also the right shape for keeping backups off the server. For how storage sits inside the rest of the bill, what a VPS actually costs breaks down the line items.

FAQ

Is an SSD VPS the same thing as an NVMe VPS?

Every NVMe VPS is an SSD VPS, because NVMe drives are flash. The reverse does not hold. A plan advertised as "SSD" may be a SATA SSD, which is flash behind an interface designed for mechanical disks, with a 32 command queue and a ceiling near 550 MB/s. Both are far quicker than a hard disk. If the gap between them matters to your workload, ask the provider which one the plan uses instead of reading it off the plan name.

Does an SSD VPS make my website faster?

It makes disk work faster, and only disk work. A page that runs several database queries per request gets faster, because those queries and their commits are small random I/O. A page served from memory or from a cache never touches the disk on the way out, so it changes very little. Measure which part of a request is slow before you pay for storage to fix it.

How can I check whether my VPS really uses SSD storage?

From inside the guest you cannot verify the physical hardware. lsblk -d -o NAME,ROTA shows what the virtual device advertises, and the hypervisor decides that value, so a 0 there is a hint rather than proof. The practical check is a measurement: run fio with a random 4k read workload for several minutes and look at the latency it reports. Single digit millisecond random reads point at spinning disks or at a congested network volume. Tens of microseconds point at local flash.

Is network attached SSD storage worse than local NVMe?

It is slower per operation and it fails differently. The network round trip is added to every read and every write, so latency is higher even though both are flash. In exchange, your data does not live on a single physical host, so a host failure does not take the volume with it, and snapshots and live migration are easier for the provider. Choose local flash for a latency sensitive database. Choose network storage when survival of the volume matters more than microseconds.