Raspberry Pi microSD card performance comparison - 2015

Variety of microSD cards tested with the Raspberry Pi model 2 B

In my experience, one of the highest-impact upgrades you can perform to increase Raspberry Pi performance is to buy the fastest possible microSD card—especially for applications where you need to do a lot of random reads and writes.

There is an order-of-magnitude difference between most cheap cards and the slightly-more-expensive ones (even if both are rated as being in the same class)—especially in small-block random I/O performance. As an example, if you use a normal, cheap microSD card for your database server, normal database operations can literally be 100x slower than if you used a standard microSD card.

Because of this, I went and purchased over a dozen different cards and have been putting them through their paces. Here are the results of those efforts, in a nice tabular format:


Card Make/Model hdparm buffered dd write 4K rand read 4K rand write
OWC Envoy SSD (USB) 64GB 34.13 MB/s 34.4 MB/s 7.06 MB/s 8.20 MB/s
SanDisk Ultra Fit (USB) 32GB 31.72 MB/s 14.5 MB/s 4.99 MB/s 1.07 MB/s
Samsung EVO+ 32GB 18.45 MB/s 14.0 MB/s 8.02 MB/s 3.00 MB/s
Samsung Pro 16GB 18.39 MB/s 18.2 MB/s 7.66 MB/s 1.01 MB/s
Samsung EVO 16GB 17.39 MB/s 10.4 MB/s 5.36 MB/s 1.05 MB/s
SanDisk Extreme Pro 8GB 18.43 MB/s 17.6 MB/s 7.52 MB/s 1.18 MB/s
SanDisk Extreme 16GB 18.51 MB/s 18.3 MB/s 8.10 MB/s 2.30 MB/s
SanDisk Ultra 16GB 17.73 MB/s 7.3 MB/s 5.34 MB/s 1.52 MB/s
NOOBS (1.4, C6) 8GB 17.62 MB/s 6.5 MB/s 5.63 MB/s 1.01 MB/s
Transcend Premium 300x 32GB 18.14 MB/s 10.3 MB/s 5.21 MB/s 0.84 MB/s
PNY Turbo (C10 90MB/s) 16GB 17.46 MB/s TODO 6.25 MB/s 0.62 MB/s
Toshiba 16GB 17.66 MB/s 11.2 MB/s 5.21 MB/s 0.21 MB/s
Sony (C10) 16GB 15.38 MB/s 8.9 MB/s 2.47 MB/s 0.24 MB/s
Kingston (C10) 16GB 17.78 MB/s 9.0 MB/s 5.75 MB/s 0.21 MB/s
Kingston (C10) 8GB 12.80 MB/s 7.2 MB/s 5.56 MB/s 0.17 MB/s
Nasya C10 16GB 16.05 MB/s 8.4 MB/s 2.28 MB/s 0.38 MB/s
No-name (C4) 4GB 13.37 MB/s < 1 MB/s < 0.1 MB/s < 0.01 MB/s

After using most of these cards in different situations over the past year or so (some for Pis running MySQL, others for file shares, and yet others just doing data logging and web dashboard displays), I've also noted that reliability-wise, all of the 16 cards I've used so far (even the no-name C4 card) have been flawless.

However, judging by performance vs. price, there are a couple clear standout cards—one is the Samsung Evo+, which is the fastest card for random access by a mile. And this year, I've seen it on sale for $10-20 for 32 or 64 GB, so it's a steal. Other than that, I'd go with the SanDisk Extreme, as it can be had for about the same price, or the Samsung Evo (without the +), as it can be had for even less if you just need 8 or 16 GB.

2015 Winner: Samsung Evo+ 32 GB (purchased for $9.99 from Best Buy)

Benchmarks

hdparm buffered

sudo hdparm -t /dev/mmcblk0

Rationale: hdparm gives basic raw throughput stats for buffered reads (by the disk/device itself). You could also test with -T instead of -t to test the OS filesystem cache performance (which allows the OS to dramatically speed up certain read operations), but for our purposes we just want to test the device itself.

Setup:

  1. Install hdparm: sudo apt-get install -y hdparm

dd write

sudo dd if=/dev/zero of=/drive/output bs=8k count=50k conv=fsync; sudo rm -f /drive/output

Rationale: dd simply copies data from one place (if) to another (of). If your filesystem caches are big enough, this is a pretty poor disk speed comparison test. Because of that, make sure that count is set to a parameter large enough to cause the OS to actually write data to the drive (e.g. 50k 8k blocks ~= 400 MB, which shouldn't be able to be cached on a microSD card in a Pi!.

iozone 4K Random read/write

iozone -e -I -a -s 100M -r 4k -r 512k -r 16M -i 0 -i 1 -i 2 [-f /path/to/file]

Rationale: iozone is a very robust filesystem benchmark tool, which does a lot of useful tests that make sure you're getting a broad overview of read and write performance for a variety of block sizes and situations. I like the lower block size random I/O tests especially, because many operations (like logging data, writing a row to an ACID-compliant database, or bulk loading of data) require as fast of small-block-size random I/O as possible.

Most cheap microSD cards, even if rated as being 100MB/sec+ class 10 cards, can't sustain anywhere near that rate when writing random data—especially on the Raspberry Pi's measly data bus. (Note that most of the above benchmarks, when run on a USB 3.0 card reader on my MacBook Air, show 5, 10, or 15 times greater performance in that environment).

Setup:

  1. Download the latest version: wget http://www.iozone.org/src/current/iozone3_434.tar
  2. Expand the tarfile: cat iozone3_434.tar | tar -x
  3. Go into the src folder: cd iozone3_434/src/current
  4. Build the executable: make linux-arm
  5. Symlink the executable into your local bin folder: sudo ln -s /home/pi/iozone_434/src/current/iozone /usr/local/bin/iozone

More Information

Check out the source for these benchmarks (which is updated every few months as I test new cards and newer versions of Raspbian): microSD card benchmarks - part of the Raspberry Pi Dramble Wiki.

Jeff Geerling is a Technical Architect at Acquia, owner of Midwestern Mac, LLC, and author of Ansible for DevOps. He is an active contributor in the Drupal community, and has primarily been a Mac user since the 1990s.

Comments

Jamie Bainbridge's picture

You can use dd with "conv=fsync" to make sure cache is flushed to disk before dd exits, therefore eliminating cache size as a variable. This is a more meaningful test than just cached dd, which doesn't really indicate anything.

Jeff Geerling's picture

Some preliminary testing indicates you're quite correct; sorry about that! I'm going to re-do all the dd tests and update this post and the Dramble Wiki page. Thanks for posting this comment!

[Edit: I've updated all the numbers in the post above.]

Personal site: jeffgeerling.com.

Suresh's picture

Jeff,

I was struggling in suggesting a good SD card for the new pi users, before I used to suggest top SD cards from amazon. But with this data, I can suggest a better card for them.

Do add an amazon link to buy.

Thanks for the research, Jeff.

Cheers
Suresh

Jeff Geerling's picture

I've run all tests on a B+ and Pi 2, and almost all numbers were within a couple percentage points. Some sustained reads/writes were faster on the Pi 2 if caching was enabled (but I didn't include those results in these listings because they measure Pi performance more than SD cards).

Personal site: jeffgeerling.com.

keshet's picture

Jeff,

Some random comments.. random read / random write are usually measured in kIOps;

I think when comparing media, the capacity (GB) is important.
Usually larger capacities (e.g., 16GB vs 32GB) use more flash dies, which means more operations can be performed in parallel. If you are comparing different capacities, you should include the capacity in the table.

--Keshet

keith's picture

Just a note - it's important to list the capacities. The same card model can perform differently at different capacity points :)

Jeff Geerling's picture

True, though I've found variation in random IO to be minimal. All are 16GB, except for a 32GB Evo+, and 8GB SanDisk Extreme Pro and Kingston C10.

Personal site: jeffgeerling.com.

Jeff Geerling's picture

Usually not. Class helps distinguish sustained read/write minimums, but says almost nothing about random IO performance, which is more important to usage in a Pi

Personal site: jeffgeerling.com.

seth's picture

It would be nice to see power cut tests on these as well. When using regular SD cards, we found most brands to eventually become corrupt in the card FTL.

Mathias's picture

Could you add the exact model of the cards? The marketing name are usually carried over several generations. When searching for SanDisk Ultra on Amazon you can get (for the 16 GB size) either SDSDQUAN-016G-G4A (rated with 48MB/s max speed) or
SDSQUNC-016G-GN6MA (rated 80MB/s), and the pictures seem identical (maybe a different shade of grey)...

Heiko's picture

Interesting results that I can confirm (sudo hdparm -t /dev/mmcblk0)

* Toshiba High Speed Professional SD-C016UHS1 @Pi2
Timing buffered disk reads: 54 MB in 3.04 seconds = 17.74 MB/sec

* Samsung Evo 16 MB-MP16DA/EU @Odroid
Timing buffered disk reads: 72 MB in 3.02 seconds = 23.88 MB/sec

Tom K's picture

I was surprised to read your comment that there was no difference in reliability between the cards. How long did you run reliability tests?

Weewx is software for weather stations, that writes to databases and logs about every 5 minutes. The cheap cards rarely survive more than a month or two. We don't know how long the best cards last, as after a year plus of testing, they are still going strong.

Did you run your tests that long?

-tk

Jeff Geerling's picture

For three cards, I have more than one year of continuous logging data (each Pi was using an Apple 5V USB power adapter): the Samsung 16GB EVO, the Transcend Premium 300x 32GB, and the Kingston C10 8GB. All three cards have performed flawlessly, writing a record into a MySQL database (that runs local on that card) every 30 seconds, 24x7.

I've also tested both the SanDisk Extreme and Samsung EVO for the past 3 months hosting http://www.pidramble.com/, on a 6-Pi2 cluster that runs Nginx, PHP, and MySQL. There are far fewer writes in that scenario, but logs are written to disk, and there's a small but steady amount of traffic to that site.

In all cases, I have not had any corruptions or failures with any of the cards. The only time I had any issue was with one SanDisk Ultra card, but I'm blaming that on a really flaky cheap micro USB power supply that I've since thrown away.

Personal site: jeffgeerling.com.

Jeff Geerling's picture

One problem with that test is that it didn't measure the cards being used from within a Pi itself (this can give vastly different results), and it also only ran the dd test (which tests large file write speed), but without the fsync option, which means buffering likely affected the results a little bit (made all the cards seem faster than they really were).

I've honestly never tried a Toshiba card, and haven't purchased a NOOBs card. Might need to pick one of each up :)

Personal site: jeffgeerling.com.

Scott Wilkinson's picture

I have recently been doing some testing on microSDs for the Pis and have tested the Samsung EVO, Samsung EVO+ and the Samsung Pro Grade 3. I am not as savvy with the the testing tools, but one huge difference I noticed was the time it took to create the initial images.

Writing the stock Raspian Jessie image -
16gb EVO 5:51 min, ~ 12 MB/s
32gb EVO+ 3:11 min, ~ 22 MB/s
32gb Pro 1:19 min, ~ 63 MB/s!

I did run hdparm, and got near identical numbers -
16gb EVO 17.56 MB/s
32gb EVO+ 18.43 MB/s
32gb Pro 18.36 MB/s

I couldn't get iozone to run on the Pi, it compiled, but keeps saying the command isn't found.

I was able to run Crystal bench on them in a USB3 reader under Windows 7. A 1GiB sequential Read/Write with a 32 deep queue -
16gb EVO 46.77 MB/s and 12.61 MB/s
32gb EVO+ 89.21 MB/s and 30.38 MB/s
32gb Pro 90.24 MB/s and 77.28 MB/s
A big difference on the write side.

4k random with a 32 deep queue -
16gb EVO 4.34 MB/s and 0.72 MB/s
32gb EVO+ 5.38 MB/s and 0.93 MB/s
32gb Pro 5.70 MB/s and 2.30 MB/s
Another big increase on the write side.

The Samsung Pro has 2 versions, Grade 1 and Grade 3. I got the Grade 3 card at Microcenter for $16. The SKU number on my receipt points to this item, http://www.microcenter.com/product/455064/32GB_Class_10_Pro_Micro_SD_Car.... But the picture and model number are wrong, that is the Grade 1 card. The Samsung Model number for the grade 3 card is MB-MG32EA/AM. The packaging on both the grade 1 & 3 cards claims 90 MB/s and 80 MB/s, and the price was the same. So I opted for the grade 3.

Jay's picture

I would love to see the Samsung PRO tested with the original and comparable setup!

Jeff Geerling's picture

Only the Envoy USB SSD. All the rest were tested by flashing them with Raspbian Lite, booting the Pi from that card, then running the tests on the command line, one card after the other.

Personal site: jeffgeerling.com.

Add new comment