Running Nextcloud on an SSD versus a hard drive changes how the app feels day to day far more than most self-hosters expect. This isn’t a benchmark exercise, it’s about whether your Nextcloud instance feels snappy when you’re browsing files, previewing photos, or syncing a laptop full of documents, or whether every click makes you wait a beat too long.
The short version: storage type matters most for the database and the thumbnail/preview cache, less for the raw file blobs themselves. If you understand that split, you can mix drives intelligently instead of overspending on SSD capacity you don’t need.
As an Amazon Associate we earn from qualifying purchases at no extra cost to you.
Where Nextcloud actually feels slow
Nextcloud isn’t just a file store. Every file listing hits a MySQL/MariaDB or PostgreSQL database for metadata, every folder with images generates or fetches thumbnail previews, and every sync client check-in triggers a bunch of small reads and writes. These are the operations that punish a hard drive, because they’re random I/O, not sequential.
A 5400 or 7200 RPM HDD handles sequential reads fine, meaning if you’re downloading one big video file, an HDD streams it almost as fast as an SSD. But a hard drive has to physically move a read/write head to find data, and that takes 5-10 milliseconds per seek. When Nextcloud’s web UI needs to render a folder with 200 files, check permissions, pull thumbnail cache entries, and update “last accessed” metadata, you’re looking at hundreds of small random I/O operations. On an HDD, that can mean folder loads taking 1-3 seconds. On an SSD, the same operation is usually under 200ms because NAND flash has no seek penalty, access time is closer to 0.1ms.
The preview/thumbnail cache is the other big offender. Nextcloud generates and caches previews for images, PDFs, and office docs. If that cache lives on a hard drive and you’ve got a large photo library, scrolling through the Photos app or a gallery view will stutter noticeably as the server reads thousands of small cached JPEGs.
The database belongs on an SSD, full stop
If you only upgrade one component, make it the drive holding your database. MariaDB/MySQL under Nextcloud does constant small writes, locking rows, updating indexes, writing to the transaction log. On a spinning disk this is where you’ll see actual lag: login taking a few seconds, the activity feed loading slowly, search queries dragging. On even a budget SATA SSD, those same operations are nearly instant because flash memory handles random writes without a mechanical penalty.
This is true even for small installs. I’ve seen single-user Nextcloud instances on a Raspberry Pi with the OS and database on a cheap high endurance microSD card feel sluggish simply because flash-on-SD-card still isn’t as consistent as a real SSD. If you’re running Nextcloud on a Pi or similar SBC, moving the database and app code to a USB-attached SSD instead of SD or spinning disk is one of the highest-impact changes you can make.
Where a hard drive is genuinely fine
Bulk file storage, meaning the actual user files behind your Nextcloud install, doesn’t need SSD speed in most home setups. If you’re storing photos, documents, backups, and media that get accessed occasionally rather than constantly re-indexed, a hard drive performs almost identically to an SSD for the actual file transfer once the metadata lookup is done. Downloading a 2GB video from Nextcloud over your home network is bottlenecked by your network speed (gigabit Ethernet tops out around 125MB/s) long before it’s bottlenecked by HDD sequential read speed (120-250MB/s depending on the drive).
This is why a lot of experienced self-hosters split storage: OS, Nextcloud app files, and database on an SSD, bulk file storage on one or more hard drives, often in a mirrored or parity setup for redundancy. It’s the same logic NAS boxes use.
SSD vs HDD for Nextcloud, by workload
| Workload | HDD experience | SSD experience |
|---|---|---|
| Folder browsing (100+ files) | 1-3 sec load, worse with more files | Under 300ms typically |
| Database queries (login, search, activity) | Noticeable lag, especially multi-user | Near instant |
| Photo gallery / preview scrolling | Stutters, delayed thumbnail pop-in | Smooth |
| Large file download/upload | Fine, network is usually the bottleneck | Fine, same bottleneck |
| Cost per TB | Much cheaper, roughly $15-20/TB | Higher, roughly $45-70/TB for SATA |
| Multi-user concurrent access | Degrades quickly past 3-5 active users | Scales much better |
What to actually buy
For a single-user or small-household Nextcloud instance, a 500GB-1TB SATA SSD for the OS, app, and database is plenty, and pairing it with a larger internal hard drive for bulk files keeps cost down while keeping the app responsive. If you’re running this on a dedicated server or NAS rather than a Pi, an NVMe SSD for the OS/database drive is worth the small premium over SATA because it also speeds up swap and general container I/O if you’re running Nextcloud in Docker.
Don’t put the database on a USB flash drive or SD card if you can avoid it. These use cheaper NAND and lack the wear-leveling and sustained write endurance of a real SSD controller, and they’ll show it within a year of constant database writes, either slowing down or developing read errors. If budget-tier external storage is your only option, at minimum size it generously so wear leveling has room to work, and back up the database separately and often.
If you’re running multiple concurrent users, a shared office syncing laptops against Nextcloud daily, skip the HDD-only setup entirely. The random I/O load from several sync clients polling simultaneously is exactly the scenario hard drives handle worst, and you’ll feel it as general system lag rather than one specific slow feature.
