Re: Got to pick the right tool for the job
"they don't scale to the same extent as the more traditional DB"
On paper maybe...but in practice...it depends on how your organise your data and then access it...most benchmarks out there don't take into account software developer bullshit.
This is where a lot of people get confused...NoSQL does scale to the same extent and often better...they just don't scale in the same way. With a NoSQL database, its often the case that RAM and CPU aren't as important as disk I/O...but disk I/O is hard to comprehend because you end up having to explain why you have a massive 20TB storage array for a 12GB database...it's tricky for devs to comprehend, because they like their traditional "just throw more CPU and RAM at it" fix, for a NoSQL database you need more throughput to improve performance, which means you need more disks to operate in parallel...it's even less intuitive when you suggest moving to nvme storage instead of hard drives...because you end up creating what appears to be a downgrade...because you end up with less storage than you started with but way more throughput...putting you in a position where you have to explain PCIe lanes, bandwidth etc etc to your customer in the face of what appears to be cutting off their server space at the knees.
A traditional SQL database can benefit massively from improved disk I/O as well, but not to the same extent a NoSQL database can, and you can hide the disk I/O problems for a long time under a mask of loads of CPU cores and tons of RAM.
In my experience, SQL vs NoSQL, SQL always hits the skids first. I've worked on a few solutions that were badly optimised and were being run on the max tier of Amazon RDS...basically the customer had reached a point where they can't "scale" anymore because there are no more CPUs and RAM options to throw at it...CPU usage at 100%, codebase a prime example of "JOINmageddon"as mentioned above.
It's much harder for a developer to fuck up a NoSQL database...a SQL database is really easy to fuck up, because optimisation of traditional SQL can result in some serious expense further down the line...for the sake of "tidy" data, you may have lumbered your client with much higher bills down the road to account for it...not only that, feature updates in the future become even harder as time goes on...need to add a new column? Well shit, you have a bunch of JOINS and UNIONS in several queries that rely on that table, but don't necessarily need that new column...those queries just got unintentionally heavier...so your new feature has an impact on performance all over the place.
TL;DR
SQL can scale better than NoSQL...but in practice and with software developer shenanigans...it is often not the case in reality.