Fashion-oriented posts like this are always a shitfest, and this one is no different. It is setting up a variety of different architectural styles as if they we

Fashion-oriented posts like this are always a shitfest, and this one is no different. It is setting up a variety of different architectural styles as if they were in competition for the "top spot", which is to say the only option that should be applied in all use cases. This isn't just garbage, it's actively encouraging a whole breed of shitty engineers who never learn how to approach solving a problem. > The goal of a NoSQL database, on the other hand, is to ensure ultimate scalability by making sure that the data is stored in a format that can be shared—or sharded—across multiple servers From here, it then proceeds to list architectural specialisms that have absolutely nothing to do with scaleability - "Document stores" excel at managing compound representations of data, they do an amazing job of minimizing IO when many small sets of (usually hierarchically structured) data can be stored as a single unit. Document stores map particularly well to the "REST" service architectures in the original Sam Ruby meaning of the word - Graph databases are (usually but not always) document stores that excel at indexing and executing transitive queries. Their innovation is not in storage, but in querying particular kinds of data sets with complex (and possibly undefined upfront) relationships using queries that are also likely complex and possibly undefined. This has more to do with expressiveness than scaleability - Column stores excel at managing timeseries. Like document stores, their entire point is IO and processing optimizations that become possible when data is in a particular shape -- varying with a particular profile, and with high redundancy when viewed along a single (usually time) axis. Column stores absolutely rock when applied to the right kind of data -- they can provide 20x storage size improvements and similar query execution time improvements. Finally we can say that column stores have something to do with scaleability. A 20x improvement in hardware utilization could very much be make or break for many kinds of common project - Time series databases are column stores. > Because companies like Google and Amazon created these databases for their own massive data stores, the goal was to reduce the time needed to grab a piece of data Every. Single. One of these architectural styles long predates the FAANG-industrial complex. > NoSQL databases don’t offer much in the way of transaction management or real coding Real coding? > NoSQL databases like MongoDB just take data and store it Nobel Prize stuff right here. I stopped reading