The new Raspberry Pi SD cards are an intriguing, if unexpected, addition to the company’s product portfolio. But just how well do they perform and are they worth the asking price?
Raspberry Pi has had a busy few months. The seemingly endless barrage of new mainline products and accessories is impressive – from AI HAT+’s and cameras to the release of the long-awaited Compute Module 5, Raspberry Pi 500 and a refreshed 16 GB variant of Raspberry Pi 5. It’s been a proper doozy, and our backed-up review pipeline still hasn’t fully recovered.
Despite there being a lot of new releases, most of these are products you’d normally expect from Raspberry Pi. Computers of all shapes and sizes, cases, Raspberry Pi-specific accessories – the usual. What we’ll be taking a look at today, however, definitely took us by surprise.
Yep! Raspberry Pi’s introduced a line of SD cards optimized for use with Raspberry Pi computers, as well as a pair of SSD drives and a matching SSD Kit designed for Raspberry Pi 5 (spoiler alert: it’s a bundle featuring the SSD itself, the Raspberry Pi M.2 HAT+, some spacers and a GPIO header).
Anyone who’s meddled with SBCs even a little (scratch that – anyone who’s meddled with any computing platform, really) should know full well how important storage performance is to overall system responsiveness. Good-quality storage really goes a long way. But with millions of Raspberry Pi boards happily chugging along for years, why the sudden need for first-party options?
To get to the bottom of this question, let’s take a closer look at the new hardware. Before we begin, though, we’d like to thank Raspberry Pi for sending over some SD cards and an SSD kit for us to play with. As always, all opinions are our own and Raspberry Pi had no say on the contents of this article.
While making this article, we’ve tinkered with its form quite a bit, settling for a two-parter in the end. In this part, we’ll be focusing on the SD card side of the lineup, while part two will focus on the SSDs. This is a first for us – but we believe it lends itself well to the overall concept.
The not-so-humble SD card
We have it good nowadays: SSD support and USB booting on modern Raspberry Pi models and built-in eMMC storage on Compute Modules. But back when it all started, there was only one option available – SD cards were the default and only practical storage medium that you could boot a Raspberry Pi board off of.
In a way, these little cards are still the go-to method for a lot of users, especially those just embarking on their SBC journey. They offer some key advantages – they are accessible, relatively inexpensive and compact. They also draw little power and are durable enough for daily use.
But boy, are SD cards not perfect.
For starters, they aren’t the fastest storage option out there. Not by a long shot, especially compared to SSDs. Most cards you’ll encounter out in the wild are of the UHS-I variety, which should, in theory, allow up to 104 MB/s transfer speeds. Take good note of that sneaky little “up to”: these aren’t guaranteed numbers under sustained use, and in practice both read and (especially) write speeds will be significantly lower. The UHS-I logo (and related UHS-II, UHS-III and EX markings) only denote the card’s interface speed, setting an upper limit. Real-world performance is just as, if not more, dependent on the actual flash chips found inside the card and the built-in storage controller.
This is where all of the various speed class markings come in – the C10’s, V30’s and U3’s of the world are there to more precisely denote the capabilities of the storage silicon itself. Unfortunately, these are also rather vague and leave a lot of leeway for manufacturers. Yet most cards have these stamped all over them. For example, one of our Kingston Canvas Go! Plus card is marked UHS-1, U3, V30, A2; while a SanDisk Ultra card we had lying around has UHS-1, C10, U1, A1 printed on it. Darn.
A more sensible review team would probably not proceed to write several paragraphs worth of text about two SD cards that aren’t even the point of the review they’re writing. However, if you’ve read an article or two of ours, you’ll know that this is exactly our forte and that we’re absolutely going to go ham breaking these down. Trust us – it’ll make it easier to understand what Raspberry Pi’s trying to do with their own card range.
So, everybody, strap in, and let’s get started!
The SD association defines three speed class ratings. The original system was simply (and aptly) named Speed Class. There are multiple ratings a card can get: Class 2, 4, 6 or 10, denoted on the card with a number enclosed in the letter ‘C’. These classes denote a minimum sequential write speed of 2, 4, 6 or 10 MB/s, respectively. Sure, there’s a few minor quirks to the system and things to consider, e.g., the way minimum speed is defined differs between Class 10 and other classes, but that’s a minor technicality we won’t bother you with.
There’s our first piece of this puzzle: the C10 symbol on the SanDisk Ultra denotes it as a Class 10 card. This means that it offers at least 10 MB/s sequential write, but less than 104 MB/s, as per its UHS-I upper limit.
The second classification system is the UHS Speed Class. There are two possible ratings a card can get: Class 1 and Class 3, denoted by the number surrounded by the letter ‘U’. Cards labelled U1 have to support sequential write speeds of at least 10 MB/s, while U3 cards up the requirement to 30 MB/s. Only UHS-I cards and above can sport one of these ratings, though this isn’t really a consideration anymore as practically every single card on the market uses at least UHS-I with old Standard Speed and High Speed interfaces being practically extinct.
The SanDisk card has a U1 printed on it, matching its C10 rating. The Kingston Canvas Go! Plus, however, has U3 stamped on it, meaning that it offers a sequential write speed of at least 30 MB/s. Again, like its SanDisk sibling, its speed should be capped at 104 MB/s due to the UHS-I bus it uses.
The third and final speed rating system is the Video Speed Class, denoted by a stylized letter ‘V’ with a number next to it. There are a number of classes available, from Class 6 to Class 90 (corresponding to baseline write speeds between 6 MB/s and 90 MB/s). Video speed classes were selected to represent the range of speeds (and some other requirements) needed for recording progressive 4K and 8K footage. There’s a little caveat, however. UHS-I cards cannot be rated higher than Class 30 on this scale, even if their write speed would otherwise net them a higher rating – those are reserved for UHS-II cards and above.
Of the two cards we’re analyzing, only the Kingston model sports a video speed class rating – it’s got V30 printed on it. In terms of raw transfer speed, this doesn’t tell us a lot more than the U3 designation. Write speeds should be at least 30 MB/s, and that’s really all we can deduce.
The annoying thing is that, even with all of these classes and ratings, we still can’t tell how fast either of these cards is exactly – for all we know, the SanDisk could be faster than the Kingston. There’s only one solution to this: off to the datasheets.
What. The SanDisk Ultra is rated at …up to 120 MB/s? And the Canvas Go! Plus has a rated read speed of 170 MB/s and a write speed of 70 MB/s. On a UHS-I bus? How—
As it just so happens to turn out, everything is a bit blurry in the oh-so-fuzzy world of SD card specifications. Why follow a well-specified standard set forth by a dedicated association with hundreds of member companies – no, that’s plain silly – just overclock the bloody thing. Crank it up! And so, SanDisk went off to create their own proprietary UHS-I extension that allows for transfer speeds of up to 170 MB/s by taking the fastest single data rate UHS-I mode (SDR104) and making it use dual data rate transfers instead, creating the monster that is DDR200.
And it just so happens that Kingston’s Canvas Go! Plus series of cards licenses this tech – and, well, the SanDisk Ultra comes straight from the source. Great.
DDR200 is problematic. Most hosts that support UHS-I cards don’t support this proprietary extension, meaning that DDR200-enabled cards won’t outperform standard (read: non-proprietary) UHS-I ones on the vast majority of devices. Worse yet, even hosts with UHS-II support (which allows for even faster transfers – up to 312 MB/s) generally don’t offer DDR200 support, instead also running these cards at their base UHS-I speed.
An easy way to confirm this is using a program like CrystalDiskMark (we’re using the default 1 MiB blocks for sequential tests, and 4 KiB blocks for random tests). Despite us using a pretty decent SD card reader for this test, without host support for proprietary speed modes both the Kingston and SanDisk card never get a result over ~95 MB/s, which is a pretty standard number for a quality UHS-I cards (though still significantly lower than the marketed speed, mind you). First, the Kingston:
…and then the SanDisk:
It’s pretty obvious that even this ~90 MB/s figure is only obtainable under ideal conditions – that is, during sequential reads. Sequential writes are already a tad slower, and random reads and writes are where stuff goes downhill rather fast. And wouldn’t you know it – operating systems do a whole lot of random reads and writes in order to, well, operate. This makes speed classes inherently a little bit irrelevant to us as they’re generally defined using sequential transfer speeds.
Starting with the SD Specification 5.1 and 6.0, the Application Performance Class standard got introduced to better inform users about cards’ performance when used as a system drive. Yep – here come the A1 and A2 we’ve mentioned. In order to get either of these class ratings, a card has to offer at least 10 MB/s sequential write speeds. However, there’s an extra requirement – Class A1 cards must offer a minimum of 1500 read operations and 500 write operations per second (using 4 kB blocks), while Class A2 cards bump the requirements up to 4000 and 2000 read and write operations per second, respectively.
Great stuff! Those A2 cards should be all the rage among Raspberry Pi owners, right? Not quite. At least, not until recently. In order to reach their target spec, these cards have some special features of their own, but also require a little bit of magic on the host side, requiring support for command queuing. Without getting into too much detail, in order to support command queuing, the host needs some specialized silicon in its eMMC controller (the CQ engine) and specialized driver support baked into the OS it’s running. Raspberry Pi 5’s BCM2712 ticks all the hardware boxes (Broadcom SoCs in older Raspberry Pi models have a standard controller which doesn’t support queuing), but back when this model launched in Q4 2023, the Raspberry Pi Linux kernel still didn’t offer command queuing support for SD cards, instead only supporting eMMC devices.
Without all the pieces in place, Class A2 cards perform as if they were Class A1 cards instead, which is still plenty snappy. However, by March 2024, Raspberry Pi’s engineering team figured out an implementation. People naturally flocked to buy fancier A2 cards and reap the performance benefit. Only one issue remained – not all Class A2 SD cards want to play nice because, to nobody’s surprise, certain models break the SD standard and flake out after a while (or straight up don’t work). What’s up with SD cards and being a little bodged together?
Raspberry Pi combatted this by tweaking the Raspberry Pi kernel to run some automated tests to enable command queuing only if the card passes, as well as check against a little file with known problematic card model IDs, just in case. There’s even a little forum thread that’s taking reports of misbehaving SD cards to potentially fix or add to the naughty list.
And apparently, all this was hit-and-miss enough to warrant Raspberry Pi’s own card lineup, developed in collaboration with Longsys (the makers of Lexar and FORESEE).
Benchmarking the Raspberry Pi SD lineup
Raspberry Pi’s SD card lineup is pretty simple: there’s a 32 GB, a 64 GB and a 128 GB card available, and they all carry the exact same set of ratings (C10, U3, V30, A2). There are also no DDR200 shenanigans here. With these being UHS-I cards, the speeds should (theoretically) cap out at 104 MB/s. In real life, we’ll probably be looking at 85-100 MB/s sequential read speeds.
As you might have noticed, these cards are A2-rated (this probably isn’t much of a surprise; we did spend quite some time talking about A2 cards just a second ago). As such, they’ll perform at their best in BCM2712-powered Raspberry Pi models like the Raspberry Pi 5 and 500. However, according to the company, special care was given to optimize and ensure snazzy performance on older models as well.
We’ve got the 32 and 64 GB variants of the Raspberry Pi SD card on hand. Let’s first use CrystalDiskMark to check general read/write speeds. Like before, we’ll be using 1 MiB blocks for sequential tests, and 4 KiB blocks for random tests.
Starting with the smaller card:
And then the larger model:
Read speeds are pretty similar between the two cards, but the 64 GB card does have a significant edge over the 32 GB model in the write department. As we’re using a Windows machine to test these, command queuing should be on.
And while the 32 GB card does perform pretty well overall, the 64 GB card is really pushing the limits of what an UHS-I card can do. That 94.33 MB/s sequential write figure is so good it’s almost a tad suspect, but we’re also using a relatively large 1 MiB block size which does help speed things along.
It’s not unusual for flash-based storage to see higher-capacity models outperform their lower-capacity siblings. This is we’re a tad bummed that we don’t have the 128 GB Raspberry Pi SD card on hand. Given how well the 64 GB one performs, however, it’s unlikely that the highest-capacity model has much more to offer in terms of speed.
Raspberry Pi OS comes bundled with a handy graphical fio-based tool for benchmarking SD card performance which gives us a simple way to check how well an SD card performs directly on a Raspberry Pi computer. For our tests, we’ll be using a 4 GB Raspberry Pi 5 and the default sdtest.sh script which ships with the OS, keeping the default 4 MB block size for sequential tests and 4 kB block size for random ones.
We also tracked down some commonly used SD cards lying around our lab to compare against. In order to avoid having to flash Raspberry Pi OS over and over again (and, partially, so we could format each card immediately prior to the test), we decided to boot off of an SSD (ooh, part two foreshadowing) and change a line or two in the sd_bench.fio file to make it point to the – now external – SD card mount location.
As we were running a fresh OS install – and since the bootloader on this Raspberry Pi already got an update a few weeks ago due to an unrelated project – we were ready to benchmark!
This batch of scores was obtained with command queueing on. Of the cards tested, only three support – the Kingston Canvas Go! Plus, and the two Raspberry Pi-branded cards. The SanDisk Ultra and the SanDisk Extreme are both A1-rated, while the Flexxon FxAdv II comes with no application performance class rating.
The 64 GB Raspberry Pi SD card sits comfortably ahead of the pack, with the 32 GB model being no slouch either, outperforming pretty much every other card but the Canvas Go! Plus. There are a few numbers on this chart that are worth commenting on, though.
For starters, the 64 GB Raspberry Pi card didn’t quite manage to push out that impressive sequential write figure from a second ago. Whether this is a Raspberry Pi-related limitation or something to do with the differences in OS implementations of command queuing is still a bit unclear. Heck, we’re still not a 100% sure that the CrystalDiskMark score wasn’t a bit of a dud, so take it with a grain of salt – the ~70 MB/s figure we got here looks a tad more believable.
Another surprise to us was how little overall effect command queueing had even with A2-rated cards in the mix (at least on this tests – more on that in a second). The smaller of the two Raspberry Pi card gets a more noticeable performance boost, but it’s still relatively minor.
However, the Kingston Canvas Go! Plus kept giving us absolutely identical results no matter whether command queuing was enabled and disabled – even though it’s an A2-rated card. One quick dmesg | grep mmc0, and we immediately spotted the issue: command queueing just wasn’t getting enabled at all! (Well, to be a bit more precise, Raspberry Pi OS has a whitelist of known good cards that are safe to enable command queueing on — as well as some checks that it performs in the background. Kingston cards are known to cause issues with queuing enabled, so it’s likely that the card either isn’t on the whitelist, or behaved a bit off during the checks.)
In order to better showcase the difference that command queuing can make, let’s dig back into the sd_bench.fio file and change the sequential read and write tests to use 4 kB blocks. This time around there’s a huge performance boost to sequential write speeds.
This sort of operation (sequentially writing many small files) is something operating systems also do a whole lot, so the performance boost offered by A2-rated cards (or at least those that actually want to play nice and work as they should) will definitely make a difference.
Overall, these are some great results and a huge win for team Raspberry Pi. They’ve managed to design a lineup of cards that outperform most of the popular options on the market (or at least, most of the options we’ve had on hand) and that’s commendable. And with a reputable company – Lexar – actually building these, they aren’t just rebadged cheapo cards. They’re the real deal.
Conclusion, pricing and alternatives
So, Raspberry Pi made some mean SD cards. But should you get them? It really boils down to two things: how much value these cards offer compared to other SD cards, and whether you should still even consider an SD card for your SBC nowadays.
Let’s tackle the first question. A bit strange for a Raspberry Pi product, there’s no official MSRP listed anywhere (or at least we couldn’t find it). Fret not, we dug around a little and checked some big-name resellers across the globe to try and piece together a picture.
SparkFun and Adafruit both sell the 32 GB version for $9.95 at the time of writing, with the 64 GB model going for $14.95 and $11.95, respectively. (Why such a difference?) The 128 GB version wasn’t listed on either store, so we’ll assume that it’s temporarily out of stock. This is solid pricing, though third-party cards of similar quality can be found for a bit less (but then again, even though Kingston’s a reputable brand, we did run into some compatibility issues).
Over in Europe, the situation is a little different. Berrybase offers the 32 GB model at a significantly cheaper 4.60 €, with the 64 GB model going for 6.70 €. This time around, the 128 GB model is available, though it’s significantly more expensive at 14.50 €. Welectron and Reichelt also have very similar pricing on these. For those across the pond, these three prices translate to $4.76, $6.93 and $15.00.
Do note that depending on your supplier, your card might ship in a nice little jewel case or without any packaging, just shoved in a little plastic baggy. This doesn’t really matter a lot (to us at least). When’s the last time you got proper use out of an SD card’s wasteful retail packaging? Its absence here is a win for the environment.
In all honesty, this is extremely competitive pricing. We’ve bought much worse cards for more – and, unless our memory is absolutely failing us, that Kingston Canvas Go! Plus actually cost around $14 when we nabbed it a month or so ago. Going down the amazon.de listings for micro SD cards, the top result is a $9.31 128 GB A2 Amazon Basics card, with the next one being for a $11.09 128 GB A1 SanDisk Ultra model. We can’t vouch how well either of these perform (but taking a look at how our 32 GB SanDisk Ultra performed, we don’t expect much from the latter).
At the end of the day, these cards are a good deal. Depending on where you are, you’ll end up paying a bit more or a bit less – but at the end of the day, you’ll have a quality card that’s guaranteed to make your Raspberry Pi very happy.
And, psst, in our opinion, the 64 GB card is the best deal of the three and is the one to go for. The performance edge it has over the 32 GB model is alone worth spending a little extra. That’s not to say that the 32 GB model isn’t worth it if you’re looking to save a few pennies. The 128 GB is priced just a little too steep, and if it were just a few dollars less expensive, it’d be as killer of a deal as its smaller siblings.
Keep in mind that none of these have any official vibration or shock resistance ratings, so they aren’t quite as industrial-grade as some of the offerings from companies like Flexxon or Western Digital. If this is important to you, do check some of these options out.
That’s question one out of the way – but the other one still remains. Should you get an SD card?
We’ll say it as it is: those looking for the best possible storage performance on their Raspberry Pi should just get an SSD instead. An SSD gives you more storage and it gives you significantly faster storage. What’s not to love here?
Power draw and price. SSDs are a lot more expensive (we’re talking , and while it might not matter too much for a one-off project, expenses like these add up fast once things scale up. If whatever you’re doing doesn’t need an SSD, you might be better off without one.
On top of that, SSDs draw a lot more power than SD cards. This might not matter if your Raspberry Pi won’t ever stray too far from a power outlet, but mobile battery-powered projects have to optimize every milliwatt of power spent, and sticking with a trusty old SD card can be a great place to start.
Finally, the way SSDs are implemented on the Raspberry Pi 5 itself is a bit limiting. By taking up the only available PCIe lane and also blocking GPIO access due to the nature of the M.2 HAT+’s design, they do limit the very hackability of your board. And if you’re interested in AI projects with the Hailo-8 or Hailo-8L, tough luck. You’ll have to look into third party HATs if you want to dual-wield one of these accelerator modules and an SSD (which, of course, comes with a performance penalty due to shared bandwidth).
Older Raspberry Pi models, like the Raspberry 4B, don’t even support SSDs – and (somewhat surprisingly), the brand-new Raspberry Pi 500 doesn’t either. If you’ve got one of these, there’s no dilemma: SD cards are the way to go.
Another alternative would be USB booting, but it generally doesn’t offer too much of a performance upgrade while being somewhat less reliable than using an SD card, if only for the fact that it’s much easier to knock a plugged-in USB drive out of its port than it is to somehow work an SD card loose.
We’ll explore the SSD option in particular more in part two. But for now, if you’re looking for a quality SD card and Raspberry Pi’s first-party option is in stock near you, give it a shot! These cards are quite solid little performers and are guaranteed to get along nicely with your other Raspberry Pi hardware.
- Raspberry Pi’s new storage options reviewed – Part 1: the SD cards - 02/04/2025
- Raspberry Pi AI HAT+ (26 TOPS) review - 01/04/2025
- Raspberry Pi AI Camera review: Even more approachable AI - 10/22/2024