SanDisk is a well-known name in the flash memory industry. Founded in 1988, they developed the first flash-based SSD. They were later acquired by Western Digital in 2016, before being spun off as a public company in early 2025.
SanDisk is a name I’ve long been aware of, and one that — prior to this project — I was biased in favor of. I have a number of single-board computers that take microSD cards, and I typically defaulted to the SanDisk Ultra 16GB for their storage — and most of the time, had no issues with them. And since they’re such a major brand, I wanted to make sure they were properly represented in this project.
I purchased these cards because I wanted to have some industrial-grade cards represented in this survey; additionally, I seem to be on a mission (whether I intended to or not) to evaluate all of SanDisk’s offerings.
These cards were delivered to me in a simple plastic case — I’m assuming the reason is because SanDisk doesn’t sell these individually, so a reseller split them up and put them into these cases.
On the performance front, these cards were slightly below average overall. Sequential read speeds were this card’s strong suit — but even those scores were just “meh”. Here’s how things shook out in each category:
- Sequential read: All three scores were slightly above average, falling between the 49th and 53rd percentiles (as of the time of this writing).
- Sequential write: Sample #2 was just a tiny bit above average, while the other two samples were just slightly below average. All three scores fell between the 48th and 58th percentiles.
- Random read: All three scores were slightly below average, falling between the 36th and 46th percentiles.
- Random write: Sample #3 did slightly worse than the other two, coming in at the 29th percentile. The other two samples came in at the 45th and 48th percentiles.
On the endurance testing front:
- Sample #1’s first error was an unrecoverable read error during round 17,852. It continued to chug along until round 18,284, when every attempt to read from the card would result in an I/O error. I let this card go for way too long — 7 months, in fact — to see if it could work its way past the I/O errors; but eventually it decided that it had enough and stopped responding to commands.
- Sample #2’s first error was a series of write errors during round 19,750 that only seemed to resolve itself when I stopped and restarted the endurance test (even switching card readers didn’t help). However, it really started having issues during round 20,766 — when attempting to read from certain sectors would just result in I/O errors. Like sample #1, I decided to just let the program run to see if it could work past the I/O errors. My program spent 6 weeks trying to work past those I/O errors before the card decided it had enough and stopped responding to commands.
Sample #3 survived 20,876 read/write cycles; during round 20,877, it got to the point where pretty much all attempts to read from the card would result in I/O errors. Chronologically, this was the first out of the three to start experiencing issues; and rather than let it try to work past the I/O errors (like I did for the other two samples), I decided to declare the card “dead” when it became apparent that they wouldn’t stop. On an interesting side note, this card is the current recordholder for “most number of read/write cycles completed per day during endurance testing”, at 219.75.
This card was tested on a dedicated reader, on a machine whose USB bus wasn’t being overloaded. This means that the read/write stats — that my program logs once per minute — should be fairly representative of how this card would normally perform. So, let’s have a look:
From this data, you can see a noticeable dip in performance around April 30th. What happened around that time to cause that? ¯\_(ツ)_/¯ I did have a power failure that affected this machine — but that didn’t happen for several days afterwards. I honestly have no idea what happened to the card or the host machine (if anything) that would have caused this.
As it so happens, Western Digital (who owned the SanDisk brand at this point in time) publishes a product brief for these cards. How do my results stack up against what Western Digital advertises? (For the record, the cards I have are model number SDSDQAF3-008G-I — at least, according to the Amazon page I bought them from.)
- Performance: Western Digital claims that these cards should be able to get sequential read speeds of up to 80MB/sec and sequential write speeds of up to 50MB/sec. All three samples got above 80MB/sec sequential read speeds, but none of the three even made it close to the 50MB/sec mark for sequential write speeds.
- Endurance: Western Digital claims that these cards should be able to endure 384TBW (terabytes written)1. However, none of the three samples made it even halfway to that mark before failing completely: the best of the three racked up just shy of 166TBW before failing, while the worst of the three racked up 145TBW.
Overall? Performance was only average. Endurance — if we look at it from the perspective of industrial-rated cards — was pretty poor. Honestly, the Kingston Industrial 8GB outperformed this card in pretty much every metric except for price. However, if we compare them to all other cards, endurance was actually pretty good — they lasted about 2-3x more than the current average (as of the time of this writing). I think I’d say that if you want something that will endure longer than most other SD cards and price is more important to you, then go with this one. But if you’re will to shell out the extra money, I think my advice would be to go for the Kingston Industrial’s.
Side note: There is an important takeaway from these results: all three failed completely shortly after experiencing their first error. So if you have one of these and start to notice issues, my advice would be to replace it as soon as possible!
1The product brief don’t specifically define whether they use terabytes (1,000,000,000,000 bytes) or tebibytes (1,0244 bytes) for the purposes of their endurance figures — but they do have footnotes elsewhere in the document defining 1MB as 1,000,000 bytes and 1GB as 1,000,000,000 bytes — so I’m going to assume that they’re defining 1TBW as 1,000,000,000,000 bytes written.
July 1, 2025