@Vérace TBH, I think schema flexibility that NoSQL is supposed to offer, is a good idea as a concept, for specific use cases. But NoSQL as a conquest unfortunately erupted a large number of second rate database systems that left out all the other good parts of traditional database systems, IMO.
Then the traditional SQL database systems implementing JSON is a good clap-back as way to say hey if you need schema flexibility, here you go when you need it, and all the good things about a relational database system are still here for you for most of your use cases too.
@J.D. This is more of less what I'm saying - unfortunately erupted a large number of second rate database systems that left out all the other good parts of traditional database systems, IMO. - the "baby-with-the-bathwater" argument - removing ACID guarantees. The "Cambrian explosion" of NoSQL systems has been well-documented. schema flexibility, here you go when you need it - i..e "Thanks lads, we're taking the good bits and leaving you with the junk!".
We agree - I think that ACID is vital for a database - maybe to be suspended on occasion but "en pleine connaissance de cause" (i.e. know what you're doing) - a bit like when INDEXes and even FK constraints are deactivated when doing bulk data loads - it's a trade-off - but speed (and/or "distributed"/"cloud-native") at all costs leads to many (all?) of the problems with NoSQL.
IMHO, systems to watch are CockroachDB, Yugabyte and TiDB where NoSQL (distributed CoW LSM Trees (RocksDB/Custom), Raft/Paxos) concepts are being married with ACID and SQL. In the PostgreSQL space, CitusDB, TimescaleDB, Orioledb & NeonDB appear to be interesting (sharding, columnar storage, CoW WAL... an active space indeed). I also think that Intel's Optane technology - with bit-addressable storage will make a comeback and have a significant impact on the database world generally. YMMV! :-)
