Raspberry Pi Cheap SSD Upgrade Guide

I’ve covered the benefits of taking your Raspberry Pi to a solid state drive (SSD) before extensively in this article but in a nutshell you get around a 280% increase in raw throughput and a 1000% increase in 4k random read/writes over a MicroSD card.

That’s fantastic but SSDs have traditionally been very expensive costing you as much as 4+ Raspberry Pis so it seemed silly to use a drive like that as Pi storage. Until now.

What if I told you...  SSD is now cheaper than MicroUSB

That’s right. Thanks to technologies such as 3D NAND flash solid state drives for consumers have now become cheaper than mid-high range MicroSD cards. With 10x the performance of MicroSD cards they are now a no-brainer upgrade for servers or IO intensive Raspberry Pi projects.

Why Choose SSD?

MicroSD cards were not designed to serve as living storage for operating systems. They are designed for devices such as cameras and smart phones that need to write and reliably store data. They’re very good at this and some cards have excellent throughput fast enough to even record 4K video.

But one thing they are not good at is 4k random writes and rewrites. These are small writes throughout a disk and consist of about 25% of all hard drive activity on a computer. Almost every action you take and even routine log file updates trigger these updates so they are very important for performance.

To show you the difference in performance I have developed a benchmark that anyone can run and uploads the results to the site. Click here to see benchmark results.

As you can see all of the top spots in the results are held by solid state drives. Further, solid state drives beat the fastest MicroSD cards by about 300%.

MicroSD performance varied wildly based on quality of the card. But even the very best and most expensive MicroSD cards got absolutely destroyed by even the cheapest solid state drives. This is because SSDs are so fast that they are limited by the speed of the Raspberry Pi’s USB 2.0 ports.

Solid state drives also have very large write caches. This lets your Raspberry Pi push data to the drive and start doing other things and let the drive itself figure out how to organize the data. Much of the throughput and other performance differences in the above chart are because of much better and faster read/write caching.

Which SSD to Buy?

Since all models and types of solid state drives hit the Raspberry Pi’s USB 2.0 transfer speed limit you should buy the cheapest one that fits your needs!

If your Raspberry Pi is mostly stationary it’s easiest and cheapest to just use a normal 2.5″ SATA SSD with a USB adapter. Here’s my recommendation:

Kingston A400
Kingston A400

Kingston A400 SSD 120GB SATA 3 2.5” Solid State Drive*

StarTech 2.5" SATA to USB Adapter
StarTech 2.5″ SATA to USB Adapter

StarTech 2.5″ SATA to USB 3.0 Adapter* (Amazon) – (View: AliExpress*)

The Kingston A400 drive performs really well in the Raspberry Pi Storage Benchmarks. It’s a great drive and is cheaper than many mid-range MicroSD cards.

The 2.5″ SATA to USB adapter above allows us to do this. There is no power adapter needed as SSDs are low power and are powered by the Pi through USB.

The contenders for the RPI storage benchmarks
Several contenders for the RPI storage benchmarks

Compact SSD Options

If you move your Pi around a lot or need something more compact there are several options.

Option 1:  SanDisk Extreme Pro 128GB USB Solid State Flash Drive* (Amazon) – (View: AliExpress*)

SanDisk Extreme Pro USB SSD

SanDisk Extreme Pro 128GB USB SSD

There are some flash drives (a very small number) that are actually solid states. This one is the best one. I actually have a old discontinued model in my picture above. You have to be extremely careful when looking for these as 99.9% of flash drives are NOT solid states. The SanDisk Extreme Pro is a true solid state. The cheaper SanDisk Extreme and Extreme Gos are not (needs to be the pro). If you are looking at a flash drive and they don’t explicitly state it’s a solid state drive then it surely isn’t!

Option 2: Build from parts

Unless you already have an old solid state you can use the price of the adapter + the drive will likely be more than the SanDisk above. If you can find killer deals on eBay you may be able to save a little bit. Check out the “Other SSD Options” section next for some additional ideas.

Other SSD Options

There are many other types of SSDs and storage adapters you can use. For example, there is an older type of drive technology called mini-SATA or mSATA that can be found in a lot of old laptops or bought for very very cheap. I wrote an article on mSATA to USB 3.0 storage adapters here covering these.

There are also extensive M.2 NVME to USB 3.0 and M.2 SATA to USB 3.0 options available as well. You can build a M.2 SATA or M.2 NVME SSD but you need to be careful with which type of M.2 drive you have/buy. They can be B-key, M-key, or M+B keyed. By far the most common and cheap ones are SATA with a B or B+M key. The adapter I have is this one.* For a full overview of different available options check out my Raspberry Pi 4 USB Mass Storage Device Booting Guide where collectively as a community we’ve compiled the best list we can of working and nonworking adapters.

Benchmark Your Storage

To get a good idea of what kind of performance improvement you can expect you can run the exact same benchmark featured in the table above.

To run the benchmark type/paste:

sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash

Compare your results to the other benchmarks here. Pay special attention to the 4k random read/write tests such as IOZone and FIO. These best reflect everyday usage on the Pi and determine how fast it will respond and perform.

Create Bootable Drive

Creating your bootable drive is also very easy. You simply image it the same way you would image a blank MicroSD.

I use Win32DiskImager and simply select the USB attached drive just like you would with a MicroSD card and write the image. It’s very easy!

Don’t forget to place an empty “ssh” file in the /boot directory if you want to connect via SSH.

Prevent High CPU Usage

There is an issue where using a solid state drive will cause kworker to consume around 10% of your CPU all of the time. This is due to the Pi polling constantly for a Micro SD card to be inserted.

There are two ways to fix this. One is to insert a blank Micro SD card in the Micro SD slot and leave it there all the time. The other is to add a line to your /boot/config.txt. Open up config.txt and add the following:


This option will tell the Pi to only check for a Micro SD card once at bootup. This means if you want to access the card it needs to be in the Pi before it boots up.

SSD With Raspberry Pi 4

The Raspberry Pi 4 did not originally support USB booting at launch unlike the previous Pi 3 models did. This is because they actually added a physical EEPROM firmware storage chip into the board. Due to this I previously published a workaround for how to set up USB booting using a SD card as a bootloader.

Fortunately the native support has finally been released for USB booting on the Pi 4. I cover how to upgrade to the new firmware and enable native USB booting extensively in my new Raspberry Pi 4 USB Booting Guide.

SSD With Raspberry Pi 3

Once you have chosen your SSD it is time to configure the Raspberry Pi to boot off USB storage. Fortunately this is extremely simple. To enable booting from USB storage simply boot up your Raspberry Pi and run this command:

echo program_usb_boot_mode=1 | sudo tee -a /boot/config.txt

Alternatively you can put your MicroSD into your computer and open /boot/config.txt and add the line:


Now reboot your Pi and USB boot support will be permanently enabled. This only needs to be done once per Raspberry Pi as the change is permanent.

You may now remove the Micro SD card altogether and plug in your external storage you prepared in the previous section. Power up the Pi and it will boot directly from the USB storage!

SSD with Raspberry Pi 1 / 2 / Zero W

The older Pi family and the Zero / Zero W also support USB booting with a small catch. You still need to have a Micro SD card inserted in the Pi with only one file on (bootcode.bin). This is because these Pis use the older
BCM2835 which is a Micro SD only bootloader.

The good news is that if we put a otherwise blank Micro SD card in there with this file the Pi can boot from USB storage just fine and take full advantage of the increased speed and storage size. Bootcode.bin basically provides the instructions to the Pi telling it how to boot from USB.

First you will format your Micro SD card as FAT32 . FAT32 is the partition type that the Pi bootloader can read and is the same format as the /boot/ partition on a fully imaged Pi card.

Next grab the latest bootcode.bin from the official Raspberry Pi repository at https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin

Copy the bootcode.bin file onto your newly created and otherwise blank FAT32 imaged Micro SD card and then insert the Micro SD card back into the Raspberry Pi.

Now connect your USB storage back to the Pi and power it on. The Pi will boot directly from your USB storage device!


A solid state drive is the biggest upgrade you can give your Pi. When I am configuring my Minecraft Raspberry Pi servers the performance difference is night and day. They boot faster, respond faster and write/read much faster. It’s very difficult to go back to MicroSD after using one of these with your Pi.

This should be a future proof upgrade as well because presumably the Raspberry Pi 4 will have USB 3.0 and support much higher transfer rates. At this point the individual performance of SSD drives might actually matter but for at least the next couple of years until the Pi4 comes out it makes sense to buy the cheapest drive possible.

I highly recommend running the benchmark for yourself to get an idea of how much performance you can gain!

31 thoughts on “Raspberry Pi Cheap SSD Upgrade Guide”

  1. Avatar for Andrew

    Hi! I’m using the “Raspberry Pi Imager” to copy Raspbian onto my SSD… It should have 120 GB but after copying the image over the size is 16 GB — I tried expanding the file system but it doesn’t have any effect. Any ideas?

    Best regards,

    1. Avatar for jamesachambers

      Hey Andrew,

      Usually the Pi will resize the partition for you on it’s first startup. You can also choose the option to expand the filesystem inside raspi-config.

      I’d try proceeding and after your first startup you should show that the entire drive is being used!

      1. Avatar for Andrew

        That’s what I did. I booted the Pi (headless), ssh’d on to it and ran sudo raspi-config to expand the file system. Here’s the output:

        Welcome to fdisk (util-linux 2.33.1).
        Changes will remain in memory only, until you decide to write them.
        Be careful before using the write command.

        Command (m for help): Disk /dev/mmcblk0: 14.9 GiB, 16021192704 bytes, 31291392 sectors
        Units: sectors of 1 * 512 = 512 bytes
        Sector size (logical/physical): 512 bytes / 512 bytes
        I/O size (minimum/optimal): 512 bytes / 512 bytes
        Disklabel type: dos
        Disk identifier: 0x04adee26

        Device Boot Start End Sectors Size Id Type
        /dev/mmcblk0p1 8192 532479 524288 256M c W95 FAT32 (LBA)
        /dev/mmcblk0p2 532480 31291391 30758912 14.7G 83 Linux

        Command (m for help): Partition number (1,2, default 2):
        Partition 2 has been deleted.

        Command (m for help): Partition type
        p primary (1 primary, 0 extended, 3 free)
        e extended (container for logical partitions)
        Select (default p): Partition number (2-4, default 2): First sector (2048-31291391, default 2048): Last sector, +/-sectors or +/-size{K,M,G,T,P} (532480-31291391, default 31291391):
        Created a new partition 2 of type ‘Linux’ and of size 14.7 GiB.
        Partition #2 contains a ext4 signature.

        Command (m for help):
        Disk /dev/mmcblk0: 14.9 GiB, 16021192704 bytes, 31291392 sectors
        Units: sectors of 1 * 512 = 512 bytes
        Sector size (logical/physical): 512 bytes / 512 bytes
        I/O size (minimum/optimal): 512 bytes / 512 bytes
        Disklabel type: dos
        Disk identifier: 0x04adee26

        Device Boot Start End Sectors Size Id Type
        /dev/mmcblk0p1 8192 532479 524288 256M c W95 FAT32 (LBA)
        /dev/mmcblk0p2 532480 31291391 30758912 14.7G 83 Linux

        Command (m for help): The partition table has been altered.
        Syncing disks.

        And here’s the output of “df -h” after rebooting:
        Filesystem Size Used Avail Use% Mounted on
        /dev/root 15G 1.3G 13G 9% /
        devtmpfs 184M 0 184M 0% /dev
        tmpfs 216M 0 216M 0% /dev/shm
        tmpfs 216M 3.1M 213M 2% /run
        tmpfs 5.0M 0 5.0M 0% /run/lock
        tmpfs 216M 0 216M 0% /sys/fs/cgroup
        /dev/mmcblk0p1 253M 47M 206M 19% /boot
        tmpfs 44M 0 44M 0% /run/user/1000

        …. it looks like there are only 16 BG, right?

        Best regards,

        1. Avatar for jamesachambers

          Hey Andrew,

          Sorry for the slow reply. Did you do a resize2fs on it? Try:

          sudo resize2fs /dev/mmcblk0p2

          I don’t see this in the raspi-config output although I believe it should do this step for you. Regardless give it a try manually and then restart the Pi. With any luck it will at least give you some output to point us closer to what is going wrong.

          How was this SD card imaged? Did you use the rpi-imager tool? You may also need to run fsck on both /dev/mmcblk0p1 and /dev/mmcblk0p2 to check for filesystem errors. If the card/partitions aren’t scanning clean I’m sure the resize operation will be aborted so this is definitely worth checking. This is definitely not normal behavior though especially for a SD card which is about as standard as it gets. It seems like something is wonky and we just need to narrow it down.

          You can also do a manual resize operation. Here’s a link to a pretty good page that covers everything from the very basic to manually creating the new partitions yourself in fdisk. Creating the partitions yourself definitely has a risk that you’ll mess up and have to start over (I’ve done it before) so I would work your way up to there as a last resort and try all the other easier/safer methods first to get it going.

          If this is a brand new setup and there’s nothing to lose I would definitely suggest trying to reimage it again using the rpi-imager tool and see if it just works. The tool fixes a bunch of obscure non-obvious problems that can cause issues on the Pi related to both formatting and partitioning. For example preferring certain formatting/sector sizes, weird developer quirks across software, differences between different SD card generations/technologies, etc. Not all tools create these images and partitions correctly and it seems like something is off either with the image or the partitioning.

          Definitely let us know what you find out!

          1. Avatar for Andrew

            Here’s the output from resize2fs /dev/mmcblk0p2:
            resize2fs 1.44.5 (15-Dec-2018)
            The filesystem is already 3822976 (4k) blocks long. Nothing to do!

            fsck /dev/mmcblk0p1 yielded:
            fsck from util-linux 2.33.1
            fsck.fat 4.1 (2017-01-24)
            0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
            1) Remove dirty bit
            2) No action
            ? 1
            Perform changes ? (y/n) y
            /dev/mmcblk0p1: 355 files, 94645/516190 clusters

            fsck /dev/mmcblk0p2 yielded:
            fsck from util-linux 2.33.1
            e2fsck 1.44.5 (15-Dec-2018)
            /dev/mmcblk0p2 is mounted.
            e2fsck: Cannot continue, aborting.

            I’m using the rpi-imager and I’ve rewritten the standard Raspbian image to my 128GB SSD multiple times… I’m stumped.

            1. Avatar for Andrew

              SORRY! I take it all back. I still had an SD card plugged into the Pi :-/ … I feel silly now. I was sure that it was a brand new, ‘virgin’ Pi, but obviously, I did pop an SD card in there. Here’s the result of df -h:
              Filesystem Size Used Avail Use% Mounted on
              /dev/root 110G 3.0G 103G 3% /
              devtmpfs 1.8G 0 1.8G 0% /dev
              tmpfs 1.9G 0 1.9G 0% /dev/shm
              tmpfs 1.9G 8.5M 1.9G 1% /run
              tmpfs 5.0M 4.0K 5.0M 1% /run/lock
              tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
              /dev/sda1 253M 47M 206M 19% /boot
              tmpfs 383M 0 383M 0% /run/user/1000

              Sorry again.

              1. Avatar for jamesachambers

                Hey Andrew,

                No problem at all! I wondered if that was maybe going in since you just appeared to be using a SD card (/dev/mmcblk0 vs /dev/sda). That looks right as rain now, 103G available on your root partition is a beautiful thing!

                Thanks for letting everyone know what it was. People have told me before they have found a lot of answers like this in the comments. I know on reddit the comments are almost always better than the content too!

  2. Avatar for David Mooney

    I cannot get a Seagate Barracuda 1TB SSD to be recognised by the Pi 4
    – I can for reference, get a generic 1tb mechanical drive to work however.
    Any ideas?

    1. Avatar for jamesachambers

      Hey David,

      That is a stranger one. Is it only when booting? If you plug in the SSD just with the adapter when running an OS off the SD card does it recognize the drive?

      The first thing I would do is fsck both partitions. Even if this is a fresh image! I am guessing you’ve tried writing the image on it again but definitely try the fsck on it too. I’ve seen rare cases where fsck issues have survived imaging (probably due to imaging software being lazy/cheating and not fully wiping partitions/tables if they are the right size/type already before writing, problems with the image itself, issues like that). Sometimes HDDs can have bad sectors too but this wouldn’t make sense with the SSD. The SSDs can definitely fail though, they just do so differently.

      Which storage adapter are you using? It shouldn’t theoretically matter since a 2.5″ SATA adapter is a 2.5″ SATA adapter. There’s no HDD or SSD distinction etc. I am just wondering if it’s maybe a firmware thing for that adapter and it needs a firmware update from the manufacturer or something like that which has come up from time to time on some of the less common ones out there! There’s also a chance of the drive itself having a firmware update that will improve compatibility.

  3. Avatar for Andrew

    Hi and thanks for the great article above.
    I just wanted to share a bit of information.
    The suggested tweak
    didn’t work for my Pi4B, the green LED kept on blinking. What worked well is:

    Also, I am using Pinn OS to multiboot a number of different Linux distributions and even Android (!) from an M.2 SSD. Works like a charm!

  4. Avatar for Jim "JR"

    For those who want a very small and portable SSD option, Seagate has released a line of extremely small, USB-3 compatible, SSD external drives; the “Seagate One Touch SSD” and “Seagate Expansion SSD” in a 500 Gig and 1T version.

    They are about the size of two flash-drives side-by-side; sufficiently small that the micro-USB-3 connector has to be on the side instead of the end, and they’re actually *SMALLER* than the Raspberry Pi itself! (The picture on the box for the One Touch SSD shows the external device being dwarfed by a pair of eyeglasses.)

    As of October 15th or so, ElDorado (In Moscow Russia), had the 500G version for the equivalent of about $80 – $100 USD. The 1T version goes for the equivalent of about $120 USD. I have no idea what they go for elsewhere, (USA, other parts of Europe, etc.) I have tried to submit speed reports, but they keep dissapearing. I have rated them on the Pi-4 at sores around 7300 – 7500 using Jim Chamber’s benchmark.

    1. Avatar for jamesachambers

      It depends on the SSD. Some of them take more power than others and the USB ports will let them draw more than they are supposed to.

      For more than one drive I definitely recommend a powered USB hub.

  5. Avatar for Jeremy Niedens

    Love this upgrade….I cloned a 64GB sd card for a 120GB ssd. Now the pi can only see 64GB of the new ssd.

    I tried expanding the file size under raspi-config, but it states it’s not a SD card.

    Any ideas?

    1. Avatar for Didier B

      How did you cloned your Sd ?
      I used the SD card copy facility in the raspbian accessories, and found the files system had been silently and automatically expanded on my SSD !

  6. Avatar for Luke

    This is fantastic. My Pi2 is loads faster using a crucial 120gb ssd. I expect it will last longer than the SanDisk SD cards that my Pi routinely destroyed. Fingers Crossed.

  7. Avatar for Chris

    Followed your advice and now running/booting from an old 64GB SSD with USB adapter. One thing I noticed is that removing the micro SD card results in process KWORKER constantly running around 20% CPU or more. Quick & dirty fix seems to be to insert any old non-bootable memory card – I’m sure there are more elegant ways.

    1. Avatar for jamesachambers

      Hello Harii4,

      Thanks for the question. I have updated the article with a new section for booting a Pi / Pi 2 / Pi Zero from USB mass storage. Basically the trick is using bootcode.bin on an otherwise blank Micro SD card and the Pi will boot from USB!

        1. Avatar for Jason

          Hi, i followed the instructions, and added “bootcode.bin” to an otherwise blank Micro SD card, but my RP2 B v1.1 was not able to boot up using usb SSD drive. Can I get some help here? Thank you!

          1. Avatar for Jason

            dropping a note regarding my previous comment. i was able to get this working when I made sure both micro SD card and SSD have the drive name “boot”

Leave a Comment

Your email address will not be published. Required fields are marked *

Type here..