You (Probably) Don’t Need Shared SSD Hosting!

Table of Contents

How is SSD Hosting Different?

The differences between SSDs and HDDs are simple to explain. SSDs don’t have moving parts, don’t spin, and don’t wear out. The lack of moving parts means that SSDs are faster than HDDs. Much, much faster! Their read/write speeds blow HDDs out of the water. There are so many reports and benchmarks that it’s not worth linking to the reports. The facts are clear – SSDs deliver superior performance.

But….?

The Con of SSDs

Today, the main downsides of SSDs are cost and storage capacity. SSDs offer a fraction of the storage space compared with HDDs for the same price. Take a look at the InMotion dedicated server page, for example. The same server has two options:

1. 2×2 TB HDD or
2. 1×500 GB SSD

That means you can get up to four times more storage with an HDD than with an SSD. Conversely, if you want the same storage on an SSD that you get with an HDD, you will have to pay more. This is why Hostgator can offer unlimited storage so cheaply.

But That’s Not the Real Issue!

Despite what it looks like, these are side issues. Technology can always catch up. SSDs will become cheaper, and they’ll increase in capacity. So these differences might not hold water for long.

The real question is: Does it make your website faster? And the answer is probably not.

Why?

Caching – Minimizing the Use of an SSD Disk

Disk access is slow – even when we’re talking about SSDs because it’s not just about raw data transfer speeds. There’s a bunch of overhead associated with each request. An extreme example is FTP. Have you ever tried to download or upload hundreds of files over FTP? It’ll take forever. Because even if you have an excellent connection and fast Internet, every file incurs an overhead that requires a sort of “handshake”.

Frequently Accessed Data

The same principle is true for regular disk access. While not as bad as FTP, web servers generally avoid using the disk as much as possible. The pattern of data access is such that most of the time, we end up requesting the same data over and over. The same files, the same queries. Like when multiple visitors request a single web page. Web servers exploit this by speeding up the delivery of often asked-for data.

They do this by storing as much information as possible in the “cache”. The cache is a particular type of blazing-fast memory – but it’s greatly limited in space. It’s also “volatile” – meaning the data is lost when the power’s switched off.

So we don’t use cache for long-term, permanent storage. Instead, we use it for frequently accessed information that we can serve quickly. The hard disk is queried a few times, and then the critical data is loaded into the cache and served the next time. This is true regardless of whether you’re using SSD hosting or not.

What Information Does a Disk Store?

A website stores two kinds of data on its storage systems:

1. Files, images, and other static content
2. Database information

CDNs for Files and Static Content

Today, most websites use CDNs to deliver static content like CSS and Javascript files. Even regular websites like yours and mine use services like Cloudflare that distribute images, etc., across multiple servers worldwide. WordPress’s “Jetpack” plugin allows you to store your static images on specialized servers for free. So your site doesn’t need to be bothered with delivering static content, and the local disks need to be queried once – that’s it. The rest of the time, your CDN takes over and doesn’t bother your site.

So no great use for SSD hosting here.

Which leaves the database

Database Cache for Database Content

You can’t hand off your database to a CDN because that’s dynamic and needs to remain local. But even here, your servers take the load off your hard disks without knowing it! Even the best SSD hosting provider is too slow compared to the cache.

And your database has a unique cache that stores the results of frequently used queries, indexes, and other data that your disk would otherwise have to serve. Ideally, we would not want the database to be bothered at all! Not unless some new data needs updating.

But is the Database Cache Enough?

The only question remains – is the database cache large enough to hold almost the entire database?

And the answer for most websites is yes!

MySQL is the database of choice for WordPress – the most popular CMS. MySQL uses the InnoDB storage engine, which has the “innodb_buffer_pool_size” variable. This is the size of the database cache. So before you think you need the best SSD hosting, look at your database cache first.

Comparing the InnoDB Cache to the Entire Database

Since you’re probably searching for WordPress SSD hosting, I’ll use the WordPress database as an example. To see whether our InnoDB cache can keep our entire database in memory, we need to compare the cache size with the database size. We’re good if:

InnoDB cache > Database size

So let’s find out.

Getting the InnoDB Database Cache Size

Here’s a tutorial I wrote earlier on how to determine the size of the InnoDB cache. Unfortunately, you can’t just get it from cPanel, and instead, you require SSH access to your site. So first, get SSH access to your site, then get the size of your InnoDB cache using the tutorials linked above.

As you can see here, my “innodb_buffer_pool_size” is 0.25 GB. Or 250 MB. Do you say that doesn’t sound like much? Perhaps. But keep in mind that your database is nothing but text. And text is very cheap to store on disk.

Getting your Database Size

One way to find your database size is to log into your cPanel, and navigate to phpMyAdmin like this:

Once you’ve logged into your phpMyAdmin interface, select your site’s database from the list on the left-hand side. For WordPress, you can get the name of your database by peeking at your “wp-config.php” file in the root folder of your installation.

Once you select the correct database, Find the “Export” tab on the right-hand side, and choose “Quick Export”, and “SQL” from the drop-down box. Then click “Go”.

This will download your entire database in the form of a “.sql” file. It’s nothing but plain text. When it’s done downloading, right-click on the file on your computer and click “Properties”. This will give you the size of your database.

Here’s the database size for this website – wp-tweaks.com as of now:

It’s just 6.4 MB! My database cache is literally 40 times bigger than my database! Once it’s primed, my server need never access the database via the disk, and it can rely entirely on the cache.

What  About Larger Sites?

Now I know what you’re thinking. “Bhagwad, your site is too insignificant and small. Larger sizes will have bigger databases and need SSD hosting!”. And you’re right. For example, my other blog www.bhagwad.com/blog/ has been around for far longer, and here is the database size:

35 MB. Larger than 6.4 MB for sure, but a hell of a lot more to go before it hits the cap of 250 MB, which is the InnoDB buffer size for my shared hosting.

Increasing the InnoDB Cache Size

On top of this, we can also increase the InnoDB buffer size if our database is approaching the limit. In most cases, increasing the RAM and the consequent cache size is a much more effective use of resources than switching to SSD drives.

Generally speaking, the database cache size should be around 80% of your system’s total amount of RAM. Not many other applications make such frequent use of the disk, so the database drives everything.

Does This Mean that Cheap SSD Hosting is Bad?

Not at all! As I said, I think it’s useless for most websites. However, here are the conditions where I feel SSD hosting can benefit you:

1. Your site database is enormous. Far, far bigger than can fit into the InnoDB buffer size. And increasing the RAM or the buffer is no longer feasible.
2. Your site has a lot of dynamic data that it can’t cache even for short periods. If the database data constantly changes, the cache is of limited value. The server will be querying the disk repeatedly to get the latest information.

So most of the time, you need more RAM. But if you do want to improve database performance on disk, use a solution like a dedicated VPS for your database instead of switching to SSD drives.