SQL seems to target a weird niche to me. Basic language containers (arrays, lists, etc.) tend to be much more convenient for lightweight data. No server to in

SQL seems to target a weird niche to me. Basic language containers (arrays, lists, etc.) tend to be much more convenient for lightweight data. No server to install configure and secure - everything can just live in code and the occasional serialized file. On the more heavyweight side of things, SQL isn't really amenable to GPUs - problematic for some heavyweight data crunching, or even basic computer graphics. It starts to make sense in the context of a server farm, but leaving it publicly exposed to the internet is a security fail - so the first thing you do with this networked appliance is lock it down to only be accessible from your server farm, or even just your local server via loopback if you're feeling particularly paranoid - writing your own layer that exposes a severely restricted API that only allows the exact operations you want to permit against your database. A lot of people will get this far and then still contribute to the CVE statistics on SQLI vulnerabilities, despite parameterized queries solving this problem. Or store blobs and defeat most of the point of using SQL in the first place. Or denormalize and shard their database for scaling purposes, losing many of the benefits of SQL enforced invariants in the process. It's not so much that I keep reinventing SQL on my projects, so much as I keep failing to come up with a good excuse to reinvent my existing approaches in SQL.