IMHO, SQL is an awful IBMism. Shame on Steve Jobs.
Worse: since the World Wide Web (and DOOM) started on NeXT?
I think a lot of anti-patterns inherited the: "we'll just use Sybase as our database!" and hence other SQL implementations became popularized as a result.
Don't get me wrong, drop-in replacements are probably useful lest there be too many hegemonic forces, but drop-in SQL replacements are still: SQL. ;(
Even in 1999, when I was employed by a "Pre-IPO" .net (because the dot com was owned by another company and I guess they really had their heart set on that name), they had Sybase BS, on Slowlaris. ;( It was so slow, they ended up using 3 (Resilience I think was the brand name?) other SQL databases in parallel rather than the on-board Sybase SQL that the FT-SPARC (Fault Tolerant, lock step SPARC systems) in use by the DSC (company later acquired by Alcatel) HLRs utilized.
I've seen and administered some other wonky SQL setups, but that one was undoubtedly one of the worst.
Circa 2014, the *only* job interview I managed to land in Berlin was at Research Gate (where they were very proud that they were sponsored by the Bill Gates Foundation; whereas to me: Bill Gates is a bad sign) and they were effusive that they weren't even running Windows, but a LAMP stack!
As someone, who had already run LAMP (for readers ignorant that means: Linux, Apache, MySQL and PHP) and even WIMP (yikes: Windows IIS, MySQL and PHP) but thankfully had long since evolved more reliable prod systems to at *least* FAPP (FreeBSD Apache PostgreSQL and PHP) I dreaded the chore of having to drag yet another behind the times shop to my past.
It seems as if it's wishful thinking that folks might evolve to lmdb, even though it's tried and true. Maybe Lumo (which is sort of the iteration of the proof of concept SQLightning [SQLite with LMDB innards e.g. https://github.com/LMDB/sqlightning]) will get more refined than when I last looked at its code (it seemed, very preliminary. Though as I look at: https://github.com/LumoSQL/lumosql I see the code hasn't been touched in 4 years and the .org domain isn't loading implying they lapsed out entirely, which is not a good sign)? LMDB is pretty groovy, SQL? Not so much.
Maybe now that "Optimal Bounds for Open Addressing Without Reordering" is published (arxiv.org link to paper here: https://arxiv.org/abs/2501.02305 some Python [yuck] proof of concept implementation here: https://github.com/sternma/optopenhash ) we'll see some other meaningful improvements in the field?
Most code rarely actually *needs* more than a hash table, and SQL IMHO, is almost *always* overkill.
Alas, due to our ancestors, a lot of dumb decisions (but maybe at the time they seemed "smart"?) were made, because it was there; and we get to keep suffering for it, because refactoring things most would prefer to avoid, even if it might be the correct approach in the long run, because we should know better now?
*sigh* wishful thinking!
