Sabrent Rocket Q4 2230 2TB SSD Review: Double the Rocket, Double the Fun

QLC flash doubles the capacity of the original Rocket 2230.

Sabrent Rocket Q4 2230 2TB SSD
(Image: © Tom's Hardware)

Tom's Hardware Verdict

The Sabrent Rocket Q4 2230 is a good choice to upgrade to 2TB for your device, such as the Steam Deck or ROG Ally. Performance is good enough to get the job done, especially for the PCIe 3.0 Steam Deck, but its QLC flash holds it back from being the best.

Pros

  • +

    2TB in the M.2 2230 form factor

  • +

    Performs well enough in PCIe 3.0 mode (Steam Deck)

  • +

    Readily available in retail with support

Cons

  • -

    Poor sustained and peak PCIe 4.0 performance

Why you can trust Tom's Hardware Our expert reviewers spend hours testing and comparing products and services so you can choose the best for you. Find out more about how we test.

If you’re a Steam Deck owner, you have undoubtedly heard of the Sabrent Rocket 2230, an early retail M.2 2230 NVMe SSD that helped DIYers upgrade once-space-limited Steam Decks. However, even the original Rocket 2230’s 1TB maximum could be tight with modern games and lots of ROMs, but thankfully now you can reach up to 2TB with Sabrent’s follow-up Rocket Q4 2230. 

SD cards and external storage can only do so much with the Steam Deck and other handhelds, and if you want easily-portable, high-performance storage, a good NVMe SSD is hard to beat. The Sabrent Rocket Q4 2230 is an easy way to upgrade your Steam Deck, ROG Ally, or other portable device to 2TB of fast internal storage. It doesn’t cut corners by using old technology, it's relatively fast and efficient, and it's more than enough to get you gaming on the go. To provide 2TB of capacity in the M.2 2230 form factor while being single-sided, it has to compromise by using QLC flash instead of the faster TLC flash. The QLC flash reduces peak and sustained performance, but the drive performs well enough where it matters.

The drive is supported by a normal retail warranty and comes with Sabrent’s copy of Acronis True Image. The drive arrives with a copper-infused heatspreader label, which might require adjustment in some devices (such as with the EMI sleeve in the Deck). Currently, the only readily available TLC-based option in this form factor is the WD SN740, the client version of the WD Black SN770, although we may see more alternatives thanks to the 232-Layer generation of flash.

The Rocket Q4 2230 is very similar to the Crucial P3 Plus and the Crucial P3. These drives are efficient and generally run cool. Like with the Crucial P3 and P3 Plus, the Rocket Q4 2230 opts for a large pSLC cache, which reduces sustained performance compared to a drive like the Solidigm P41 Plus.

The Micron 2400, another popular 2TB choice for M.2 2230 SSDs, uses the same controller as the P41 Plus — the SMI SM2269XT — but comes with Micron’s QLC flash. That controller tends to be less efficient, and it’s possible the Micron 2400 has a larger pSLC cache, making the Rocket Q4 2230 arguably the best all-around QLC-based option for embedded devices at this time. Let's see how it performs. 

Specifications

Swipe to scroll horizontally
Product1TB2TB
PricingN/A $219.95
Form FactorM.2 2230M.2 2230
Interface / ProtocolPCIe 4.0 x4 / NVMe 1.4PCIe 4.0 x4 / NVMe 1.4
ControllerPhison E21TPhison E21T
DRAMN/A (HMB)N/A (HMB)
MemoryMicron 176-Layer QLCMicron 176-Layer QLC
Sequential ReadN/A5,000 MB/s
Sequential WriteN/A3,200 MB/s
Random ReadN/A480K
Random WriteN/A750K
SecurityN/AN/A
Endurance (TBW)N/A450TB
Part NumberSB-213Q-1TBSB-213Q-2TB
Warranty5-Year5-Year

The Rocket Q4 2230 is currently available only at 2TB for $220 on Amazon. Price swings are common in the SSD market, and the competition's pricing also varies.

Although Sabrent appears to have left the door open for a 1TB SKU, the 2TB is the only one currently available. It peaks at 5,000 / 3,200 MB/s for sequential reads and writes and 480K / 750K random IOPS. Write speeds can be lower for QLC, although this rated value is below what the drive can achieve, and it has enough speed to saturate the PCIe 3.0 bus present in the Steam Deck.

The drive is warrantied for five years with registration, and the drive can absorb up to 450TB of written data. This endurance rating is more than sufficient for the drive’s use in a device like the Steam Deck. Worries about QLC endurance are not warranted; Micron’s 176-Layer QLC is normally rated for 1,500 program/erase cycles with up to 100,000 in pSLC mode.

Software and Accessories

The Sabrent Rocket Q4 2230 comes with a downloadable, Sabrent-specific version of Acronis True Image which is useful for cloning and imaging. This can be nice to have, especially when working with the ROG Ally. Sabrent also has its own SSD toolbox, which will presumably offer firmware updates for the drive, if applicable.

A Closer Look

The Rocket Q4 2230 arrives in a stylish tin, showing off a mixture of white and copper coloring. While not important, the presentation is attractive and does separate it from many OEM SSDs. The drive’s label operates as a heatspreader as it is made of thermally-conductive copper.

The Rocket Q4 2230 sports an SSD controller and a single NAND package. The drive is single-sided, which is important for many embedded devices like the Steam Deck — it can be a challenge to pack in 2TB of flash with this limitation. 

The Rocket Q4 2230 uses Micron’s 176-Layer QLC (N48R) flash, which is convenient for achieving 2TB in such a small package. In contrast, the original Rocket 2230 was constrained to 1TB because it used Micron’s 176-Layer TLC (B47R).

Using 1Tb dies with TLC flash is possible, as the WD SN740 does with BiCS5, but that flash is less efficient. SK hynix also makes 1Tb dies, but given current stacking technology, we will likely see 232-Layer generation flash tackling this role (aside from maybe BiCS6), such as with Micron’s B58R TLC. This flash is already available on many drives, like the Crucial T700

The Rocket Q4 2230 is DRAM-less, but the host memory buffer (HMB) feature is supported on Valve’s Steam Deck, ASUS’s ROG Ally, and other devices. This should be sufficient for portable gaming workloads. The drive is also PCIe 4.0, which begs the question: does that make a difference for the Deck? In fact, this drive is somewhat more efficient when restricted to the 3.0 interface, and it’s worth going for new hardware for overall performance and efficiency on a portable platform. Such technology does not often arrive on an older PCIe interface, and with it being backward compatible, there’s little reason not to go with a 4.0 drive.

The Rocket Q4 2230 uses the Phison E21T SSD controller, which we’ve reviewed on multiple products, including the original Rocket 2230 (a.k.a. the Rocket 2230 NVMe 4.0). This controller has a history of providing good performance and power efficiency. The latter is probably more important with battery-powered, portable devices. This controller’s primary competition would include the Silicon Motion SM2269XT on drives like the Micron 2400 and Solidigm P41 Plus, the InnoGrit IG5220, and the Maxio MAP1602. However, the latter two are less commonly found on M.2 2230. The MAP1602, on paper, is faster but can run slower, which offers some flexibility.

Future controllers, like the Phison E27T and Silicon Motion SM2268XT, could usurp its position, although the extra performance doesn’t mean much for the PCIe 3.0 Steam Deck. Efficiency gains would be nice, but these two controllers will still be 12nm. Any gains would more likely come from the flash. One other worthy mention is the Kioxia BG6 with an unknown controller. Kioxia has often used Phison controllers, and the BG6 uses Kioxia’s 162-Layer TLC (BiCS6), giving it some bandwidth uplift. Efficiency remains uncertain.

MORE: Best SSDs

MORE: Best External SSDs and Hard Drives

MORE: How We Test HDDs And SSDs

MORE: All SSD Content

Shane Downing
Freelance Reviewer

Shane Downing is a Freelance Reviewer for Tom’s Hardware US, covering consumer storage hardware.

  • abufrejoval
    I guess the biggest question is: how do you ensure it's done steady-state processing before you turn the device off?

    These gaming decks spend plenty of time not being used, so time windows for such 'batch background' processing exists aplenty... except that you might not charge it immediately and that you'd have probably turned it off, too.

    I guess even if the OS isn't really needed running, the OS will decide to put the SSD into sleep state and there is very little the SSD can do without risking to have its juice cut off, should it try to refuse.

    So you need to keep the console on after you've finished to enable the SLC->QLC transfer and the erasure block optimizations to happen.

    And in fact I guess there isn't even a proper protocol for the SSD to tell the host that it's finished doing housekeeping and now wouldn't mind being turned off.... or is NVMe a lot smarter than I give it credit for?
    Reply
  • evdjj3j
    The ratings on this site make no sense whatsoever. Jerrad claims that 3 1/2 stars on his reviews is a a C yet this review with 3 stars claims in the summary that this drive is a good buy.
    Reply
  • JarredWaltonGPU
    evdjj3j said:
    The ratings on this site make no sense whatsoever. Jerrad claims that 3 1/2 stars on his reviews is a a C yet this review with 3 stars claims in the summary that this drive is a good buy.
    A mediocre product at a good price might still be a good buy, particularly for a drive going in a Steam Deck. Not that this is a "good" price, but 2TB 2230 drives aren't really cheap right now. Also: Different people, different takes. The text is far more important than the score, in my view.
    Reply
  • JarredWaltonGPU
    abufrejoval said:
    I guess the biggest question is: how do you ensure it's done steady-state processing before you turn the device off?

    These gaming decks spend plenty of time not being used, so time windows for such 'batch background' processing exists aplenty... except that you might not charge it immediately and that you'd have probably turned it off, too.

    I guess even if the OS isn't really needed running, the OS will decide to put the SSD into sleep state and there is very little the SSD can do without risking to have its juice cut off, should it try to refuse.

    So you need to keep the console on after you've finished to enable the SLC->QLC transfer and the erasure block optimizations to happen.

    And in fact I guess there isn't even a proper protocol for the SSD to tell the host that it's finished doing housekeeping and now wouldn't mind being turned off.... or is NVMe a lot smarter than I give it credit for?
    If you're still copying files, in Windows, you'd see the dialog still open. For Linux, you'd have something similar. On a Steam Deck, the only thing you'd likely be doing is downloading and installing a game, which can also be interrupted. This is the whole purpose of the shutdown procedure in modern OSes, giving the OS time to clean things up before turning off.

    Powering off (via a hard switch) in the middle of doing anything can be bad. Most drives limit how much stuff sits in volatile storage (RAM caches) for exactly this reason. High-end drives would have a super capacitor to store power so that they can flush things from RAM to NAND in the event of a power loss. For consumer drives, it's possible, if you cycle the power in the middle of writes, to kill an SSD. Probably very unlikely, and it would depend on the model, but I know in the past I heard of this happening.
    Reply
  • abufrejoval
    JarredWaltonGPU said:
    If you're still copying files, in Windows, you'd see the dialog still open. For Linux, you'd have something similar. On a Steam Deck, the only thing you'd likely be doing is downloading and installing a game, which can also be interrupted. This is the whole purpose of the shutdown procedure in modern OSes, giving the OS time to clean things up before turning off.

    Powering off (via a hard switch) in the middle of doing anything can be bad. Most drives limit how much stuff sits in volatile storage (RAM caches) for exactly this reason. High-end drives would have a super capacitor to store power so that they can flush things from RAM to NAND in the event of a power loss. For consumer drives, it's possible, if you cycle the power in the middle of writes, to kill an SSD. Probably very unlikely, and it would depend on the model, but I know in the past I heard of this happening.
    Just to make sure we're on the same page: I am concerned that the usage pattern of a Steam deck or console will give your device very little time to move freshly written data from the SLC cache to permanent QLC storage.

    SSD firmware is a lot like a database transaction log, that needs some idle to empty properly.

    Windows and Linux will see just a committed write, turning off the device won't loose you any data, it might just not have the opportunity to do the house-keeping and the SLC cache will remain permanently filled while the drive has to bypass it for new data resulting in HDD class write speeds.

    It all depends on just how eager the SSD is about evicting the SLC cache and how high your update rate is. If your Internet is well below 1Gbit, there is little risk it will overflow the SLC cache, if your Steam deck is receiving updates from your gaming PC NBase-T rates and SLC eviction is very lazy, things could be different.

    At 2TB for your Steam stash, at least you won't have to swap games in and out as often, which signficantly helps to lessen the write burden.

    I've never liked the unpredictability of QLC or in fact SLC caches on principle. I can't say that I've been badly hit by it either, but that's a small surprise, since I never knowingly bought any QLC devices: I went from SLC to MLC quickly but took my sweet time to switch from MLC to TLC, but then SSDs were still caching not holding entire Steam collections.

    But I've often wondered if SSDs that are only used in a very bursty manner (top load or off) might accumulate write amplification debt by their usage patterns. Modern flash drives need idle time to do housekeeping, including internal patrol reads to keep blocks from decaying beyond their ECC thresholds.

    Desktops and even office notebooks provide tons of idle, a Steam deck perhaps much less so.

    You could investigate, and make that an article: wouldn't that be fun?
    Reply
  • JarredWaltonGPU
    abufrejoval said:
    Just to make sure we're on the same page: I am concerned that the usage pattern of a Steam deck or console will give your device very little time to move freshly written data from the SLC cache to permanent QLC storage.

    SSD firmware is a lot like a database transaction log, that needs some idle to empty properly.

    Windows and Linux will see just a committed write, turning off the device won't loose you any data, it might just not have the opportunity to do the house-keeping and the SLC cache will remain permanently filled while the drive has to bypass it for new data resulting in HDD class write speeds.

    It all depends on just how eager the SSD is about evicting the SLC cache and how high your update rate is. If your Internet is well below 1Gbit, there is little risk it will overflow the SLC cache, if your Steam deck is receiving updates from your gaming PC NBase-T rates and SLC eviction is very lazy, things could be different.

    At 2TB for your Steam stash, at least you won't have to swap games in and out as often, which significantly helps to lessen the write burden.

    I've never liked the unpredictability of QLC or in fact SLC caches on principle. I can't say that I've been badly hit by it either, but that's a small surprise, since I never knowingly bought any QLC devices: I went from SLC to MLC quickly but took my sweet time to switch from MLC to TLC, but then SSDs were still caching not holding entire Steam collections.

    But I've often wondered if SSDs that are only used in a very bursty manner (top load or off) might accumulate write amplification debt by their usage patterns. Modern flash drives need idle time to do housekeeping, including internal patrol reads to keep blocks from decaying beyond their ECC thresholds.

    Desktops and even office notebooks provide tons of idle, a Steam deck perhaps much less so.

    You could investigate, and make that an article: wouldn't that be fun?
    So, the pseuso-SLC cache is still non-volatile. Even if you filled it up with sustained writes, and then immediately told the PC to shutdown, all that data is still there and "safe." The SSD would just work to flush out the pSLC cache to QLC storage once it's powered back up and basically idle. At least, that's my understanding of things, so the pSLC isn't a bad approach at all.

    Note that with a 2TB SSD, the pSLC cache could be up to 500GB in size for a completely empty drive. So, if you could do sustained writes at max speed and fill that up, and then had to drain it at ~100 MB/s, it could take over 1.38 hours just to empty the pSLC to QLC. LOL. (Related: The drives take a while to recover in our Windows testing, unless you just wipe/format them.)

    For the Steam Deck, the only way you'd really exceed even the reduced SSD write speed is if you had a wired connection. In my experience at least, you're otherwise limited by the Wi-Fi. It's a Wi-Fi 6 device (802.11ac 2x2 to be specific), which means best-case it has a theoretical 866 Mbps throughput. Except, you will NEVER see that in the real-world, even in ideal scenarios.

    Basically, Wi-Fi 6 2x2 speeds will usually max out at maybe 550 Mbps, and if you have anything else happening on the network you'll probably get more like 350 Mbps. I have an 802.11ac 2x2 router for my house, and download speeds on the Steam Deck topped out at around 270–300 Mbps consistently. I get faster than that on some laptops with similar adapters, so it's likely the Steam Deck hardware that's slowing things down.

    So if you have a hypothetical 200GB game download going, best-case it's writing to your SSD at maybe 60 MB/s, and very possibly closer to 35 MB/s. Even the worst QLC drives can basically do that all day without problems. Heck, even hard drives could do that, but HDDs are worse for power, size, and other performance aspects since they have that whole constantly spinning disk thing going on.

    It would be interesting to try testing this. Like, a decent SSD and controller should write initially to the pSLC cache, but if it's only at ~40 MB/s, the cache can then be immediately flushed to QLC and would perhaps never fill up (until the SSD is completely full). The problem is that writing even 100GB of data at 40 MB/s takes a while, about 40 minutes. I guess that would be the question: if write speeds are slow, like sub-100 MB/s, do the SSDs even use their pSLC caches, or do they just write straight to TLC/QLC NAND?
    Reply
  • abufrejoval
    JarredWaltonGPU said:
    So, the pseuso-SLC cache is still non-volatile. Even if you filled it up with sustained writes, and then immediately told the PC to shutdown, all that data is still there and "safe." The SSD would just work to flush out the pSLC cache to QLC storage once it's powered back up and basically idle. At least, that's my understanding of things, so the pSLC isn't a bad approach at all.

    Note that with a 2TB SSD, the pSLC cache could be up to 500GB in size for a completely empty drive. So, if you could do sustained writes at max speed and fill that up, and then had to drain it at ~100 MB/s, it could take over 1.38 hours just to empty the pSLC to QLC. LOL. (Related: The drives take a while to recover in our Windows testing, unless you just wipe/format them.)

    For the Steam Deck, the only way you'd really exceed even the reduced SSD write speed is if you had a wired connection. In my experience at least, you're otherwise limited by the Wi-Fi. It's a Wi-Fi 6 device (802.11ac 2x2 to be specific), which means best-case it has a theoretical 866 Mbps throughput. Except, you will NEVER see that in the real-world, even in ideal scenarios.

    Basically, Wi-Fi 6 2x2 speeds will usually max out at maybe 550 Mbps, and if you have anything else happening on the network you'll probably get more like 350 Mbps. I have an 802.11ac 2x2 router for my house, and download speeds on the Steam Deck topped out at around 270–300 Mbps consistently. I get faster than that on some laptops with similar adapters, so it's likely the Steam Deck hardware that's slowing things down.

    So if you have a hypothetical 200GB game download going, best-case it's writing to your SSD at maybe 60 MB/s, and very possibly closer to 35 MB/s. Even the worst QLC drives can basically do that all day without problems. Heck, even hard drives could do that, but HDDs are worse for power, size, and other performance aspects since they have that whole constantly spinning disk thing going on.

    It would be interesting to try testing this. Like, a decent SSD and controller should write initially to the pSLC cache, but if it's only at ~40 MB/s, the cache can then be immediately flushed to QLC and would perhaps never fill up (until the SSD is completely full). The problem is that writing even 100GB of data at 40 MB/s takes a while, about 40 minutes. I guess that would be the question: if write speeds are slow, like sub-100 MB/s, do the SSDs even use their pSLC caches, or do they just write straight to TLC/QLC NAND?
    Yup, it's at that point when you want to start reading the controller's source code.

    But then perhaps, you'd never trust it with your data again, when you see how badly even firmware can be written =:-O

    And when the firmware has to deal with things like host buffers, that require interaction with host firmware that could be buggy, too, and simply sprinkle your most critical data structures with random bits, you wonder if these firmware engineers might have burn out or a drinking problem, especially since these junior guys only get to work on the cheaper entry level products, which are much harder to handle than when you've got everything fully under your own control.

    My very first SSDs were FusionIO drives, which basically operated in host-buffer mode and a host side firmware, while the FPGA on the drive only did the lowest level signal processing and basic chores. It let me appreciate the complexity that has now transitioned into the drives themselves, which run a software stack which has your average VAX cluster look primitive by comparison.

    So I am eagerly awaiting your results and suggest you dock the Steam deck, use a 2.5 Gbit USB Ethernet dongle and let Steam stream from a big desktop locally.

    Of course you could always just run 'fio' and see what happens.

    And you obviously don't need to test this on a Steam deck, any M.2 slot in a PC will do..
    Reply
  • abufrejoval
    In the older days, I used to worry a lot about keeping enough spare area around to ensure that in absence of TRIM support my SSDs wouldn't start reflashing entire erase blocks for every 512 byte sector written.

    These days I just keep running my manual TRIMs when I do major updates and most of my SSDs never go near the 90% mark anyway before I expand or reallocate: prices below €50/TB evict quite a lot of lesser capacity drives natuerally, which interestingly have never gone near 90% remaining life in all those years.

    But... I've also had some very old Android tablets die on storage that seemed to reprogram flash at EEPROM speeds, never giving up ...before I did.

    Steam caches are a bit special, because there are actually non-critical data: if data actually were to get corrupted, all you need is wait for it to download from somewhere else.

    So you tend to get messy with it, fill your storage more recklessly. In the case of my kids it's always near 100% which has me banging my head and my kids shrugging ('never given me a problem, but I need more space..')

    What I really want is a local shared Steam cache on my 10Gbit LAN, only one copy of every game in a houshold with nearly 10 Steam devices of various kinds.

    But it turns out Windows really, really sucks at opening hundreds of thousands of little files when I open my favorite game, which is ARK survival evolved. And it sucks much, much worse, when you do that over the network.

    I had ARK running once on Linux: It loaded ARK faster from a hard disk than Windows loaded it from NVMe...
    The graphics were another issue and I love the game for its eye candy.
    Reply
  • JarredWaltonGPU
    abufrejoval said:
    In the older days, I used to worry a lot about keeping enough spare area around to ensure that in absence of TRIM support my SSDs wouldn't start reflashing entire erase blocks for every 512 byte sector written.

    These days I just keep running my manual TRIMs when I do major updates and most of my SSDs never go near the 90% mark anyway before I expand or reallocate: prices below €50/TB evict quite a lot of lesser capacity drives natuerally, which interestingly have never gone near 90% remaining life in all those years.

    But... I've also had some very old Android tablets die on storage that seemed to reprogram flash at EEPROM speeds, never giving up ...before I did.

    Steam caches are a bit special, because there are actually non-critical data: if data actually were to get corrupted, all you need is wait for it to download from somewhere else.

    So you tend to get messy with it, fill your storage more recklessly. In the case of my kids it's always near 100% which has me banging my head and my kids shrugging ('never given me a problem, but I need more space..')

    What I really want is a local shared Steam cache on my 10Gbit LAN, only one copy of every game in a houshold with nearly 10 Steam devices of various kinds.

    But it turns out Windows really, really sucks at opening hundreds of thousands of little files when I open my favorite game, which is ARK survival evolved. And it sucks much, much worse, when you do that over the network.

    I had ARK running once on Linux: It loaded ARK faster from a hard disk than Windows loaded it from NVMe...
    The graphics were another issue and I love the game for its eye candy.
    I had a 1TB Steam / etc. caching system set up at one point, back in the day. But now that I have a gigabit internet connection, it's not really useful. I do remember I had issues where often it would download the same file multiple times because of SSL or something, and I think that was also why I stopped bothering. Well, that plus fast internet plus no data cap. I am still just running gigabit Ethernet, as that's what all of my PCs support. I think one or two have 10GbE ports, but trying to rewire plus the cost of the new router has me just ignoring it for now. Maybe in another five years or so I'll finally be convinced to make the switch!
    Reply
  • saunupe1911
    I hate Sabrent. Their support absolutely sucks!!!!!! I've had 3...I repeat...3 Rocket 4 NVME die on me within 3 years. One of them was their dang replacement. Meanwhile I've had Samsung and PNY drives last even longer!!!!!!!!!!!!!!!!!

    Stop promoting these pissy products
    Reply