This is a mixed bag. As someone who worked in the storage industry for ~10 years, there are a lot of poorly defined behaviors that are vendor/model specific and I can see how its easier to just pick a particular model, test it and declare it the blessed version having done similar stuff myself.
Ex, SMART attributes, mode sense/caching behaviors, etc. Which can all be used in conjunction with RAID to determine when a disk should be replaced, or the user warned about possible impending doom, to simple things like how one sets cache WT/WB and flushes the caches (range based flushing is a thing, doesn't always work, etc) for persistence.
OTOH, much of this is just 'product maturity' because it is possible to have a blessed set of SMART/etc attributes that are understood a certain way and test to see if they exist/behave as expected and warn the user with something like "this drive doesn't appear to report corrected read errors in a way that our predictive failure algorithm can use". Or "This drive appears to be a model that doesn't persist data with FUA when the caches are set to write back, putting your data at risk during a power failure, would you still like to enable writeback?"
And these days with the HD vendors obfuscating shingled drives or even mixing/matching the behavior in differing zones its probably even worse.
So initially I wanted to give you a knee-jerk response about how Synology could have gone with a warning rather than an outright ban. Then I read the article...
It seems that this was never an outright ban, but non-blessed drives either generated a warning or they had reduced functionality. What TFA fails to mention is what this "reduced functionality" is.
If it's something like RAID rebuilds take longer because other drives might not have the requisite SMART attributes or some other function that's required is one thing. But halving the drive speed just because it's not a Synology drive is another. This knowledge would put me in a better position to know if I should harshly judge them or not.
I think it's totally fair to raise a warning that a particular drive has not been tested/validated and therefore certain guarantees cannot be met. I can fully respect how challenging it must be to validate your product against a basically infinite combinatorial collection of hardware parts. I've learnt long ago that just because a part fits does not mean it works.
I don't know the details of the warnings either, but from the original articles it sounds like they had moved to a QVL list that didn't include 3rd party devices, only their rebranded ones. Which is possibly because they got seagate/wd/etc to tweak something in the firmware. Which isn't unheard of for large vendors. And it is somewhat fair, qualifying drive persistence is probably some ugly unit test that takes hours to run, and requires being able to pull power on the drive at certain points. So the warning ends up being the equivalent of "we don't know if this drive works, lots of them don't we are going to disable this aggressive cache algorithm to assure your data is persisted" and that kills the performance vs the qualified drive. But because some non technical PM gets involved the warning shown to the user is "This drive isn't qualified".
The other take though, was that it was just a $ grab by rebranding and charging more for drives that were functionally the same. Which for logical people made sense because otherwise, why not say why their drives were better. But sometimes the lawyers get involved and saying "our rebranded drives are the only ones on the market that work right when we do X, Y, Z" is frowned on.
Hard to really know without some engineer actually clarifying.
No, it was a pretty complete ban. From a reputable reviewer[0]:
> New Installations Blocked for Non-Verified Drives
> As discussed in our NASCompares coverage and testing videos, attempting to initialise the DS925+ with hard drives that are not on the 2025 series compatibility list will block you from even starting DSM installation.
and
> Expanding Existing Storage Pools with Unverified Drives is Blocked
> Another key limitation to note is that you cannot expand an existing storage pool using unverified drives — even if your system was initialized using fully supported drives.
and
> To test RAID recovery, one of the three IronWolf drives in the migrated SHR array was removed, placing the system into a degraded state. We then inserted a fresh 4TB Seagate IronWolf drive.
> Result: DSM detected the new drive but refused to initiate RAID rebuild, citing unsupported media.
You could pull all of your drives from an older Synology and put them in the new device, but you couldn't add drives to the volume or replace crashed drives. And if you were starting with a brand new NAS, you couldn't even initialize it when using 3rd party drives.
I'm OK with a warning notice. I'm not even remotely OK with this.
By the way, their official drive compatibility list for the DS923+[1] shows dozens of supported 3rd-party drives. The same guide for the DS925+[2], an incremental hardware update, shows 0. So if you bought a bunch of drives off their official support list, they're useless in newer models. Apparently a Seagate IronWolf was perfectly fine in 2023 and a complete dud in 2025.
Oh, and Synology only sells HDDs up to 16TB in size[3], and they only have up to 12TB drives (for $270) in stock today. That price will get you a 16TB IronWolf Pro off Amazon. If you have cash to spend, you can buy a 28TB IronWolf Pro there, which is 2.3x bigger than the largest Synology you can order from the first-party store today.
Ex, SMART attributes, mode sense/caching behaviors, etc. Which can all be used in conjunction with RAID to determine when a disk should be replaced, or the user warned about possible impending doom, to simple things like how one sets cache WT/WB and flushes the caches (range based flushing is a thing, doesn't always work, etc) for persistence.
OTOH, much of this is just 'product maturity' because it is possible to have a blessed set of SMART/etc attributes that are understood a certain way and test to see if they exist/behave as expected and warn the user with something like "this drive doesn't appear to report corrected read errors in a way that our predictive failure algorithm can use". Or "This drive appears to be a model that doesn't persist data with FUA when the caches are set to write back, putting your data at risk during a power failure, would you still like to enable writeback?"
And these days with the HD vendors obfuscating shingled drives or even mixing/matching the behavior in differing zones its probably even worse.