> I cringe every time I see dongle attached storage

I'm quite curious as to how this is "cringe"worthy. I can certainly see how mechanically stable attached storage is preferable in a lot of situations, but people use Pi's for a vast array of uses, and I cannot imagine that every use case, or even a significant majority of them should be barred from USB attached storage.

> An unnecessary additional failure point seems counterproductive

One of the leading reasons for using USB attached storage on the Pi is to avoid SD card corruption issues.

FWIW I have not had any SD corruption issues after 1) using name-branded cards and 2) ensuring that I feed each Pi w/5.2V. In the end I bought a commercial 5V power supply, tweaked it up 5% and wired directly to the 5V pins on the Pi.

I'm running several Pi's from SD card, some for years, and the only issue I had was with one that randomly crashed.

Measured the resistance of the "USB charging cable" I had used for it and found it was 1 Ohm! So when the Pi peaked at 1A current draw, the cable dropped 1V.

Swapped it out for something proper (<0.1 Ohm), and haven't had issues since.

Same here. I even went as far as finding barrel-jack to USB connectors so I could wire thicker-gauge cables to the Pi.

In the end I gave up on trying to find low-ohm cables and just wired directly to the power supply. It's surprising how many cables just plain suck.

You can get the same corruption on ssds if power draw is more then pi allows or if power goes down.

With an SSD you are increasing power consumption on USB which is limited to around 1.2A or however much power supply allows.

Note: I havent had any corruptions past year on pi3... all I changed was power supply, sd card and using aarch64

Presumably using an enterprise-grade NVMe SSD with power loss protection capacitors would avoid such trouble. Some of those have reasonably low power consumption under load, but they're all bad at idle compared to client/consumer SSDs. But now you also have me wondering about Intel's Optane cache SSD modules, which like enterprise SSDs don't have any volatile caching, and they're also cheap enough to make some sense in an RPi context. I'm tempted to do some voltage margin testing on one to see where it browns out compared to a typical consumer SSD.

I disagree. The RPi is a pretty versatile little machine. Yes, it does have some limitations, and the workarounds for those (like NVMe-over-USB) are not particularly optimal, but by sticking with RPi (rather than one of the other myriad SBCs), you get consistency and a reasonable expectation that the board is still going to be supported with an up-to-date userland 10 years from now.

I've been wanting to build a 4-bay SBC NAS for years now, but I haven't been able to bring myself to trust the community and support for some of the other boards that do give you direct access to the PCIe bus so you can actually get decent performance.

Now I'm waiting for someone to come up with something based on the Compute Module 4... (There was a post about someone designing a PCB for something that would do the trick the other day, but it requires some 0.4mm pitch soldering skills that I just don't have the equipment for.)

I have found that the SD card tends to 'wear out' after a few years. Agreed USB is suboptimal; but it can work OK.

Quick plug for log2ram, which greatly reduces the write cycles on the boot SD, especially for Pi's that run 24/7: https://github.com/azlux/log2ram

>"...I cringe every time I see dongle attached storage..."

>"...If you need fast storage I believe you should buy an appropriate device"

Frankly you can cringe all you want but it is really up to the owner to decide how they use their hardware. Your opinion about it is irrelevant as people have their unique situation and are quite capable to weigh all pros and cons of whatever they decide to do.