There is an interaction here between the "what gets measured gets managed" principle and the sunk cost fallacy. The problem with databases is actually complexity. Any individual feature is more or less safe, but around the time reliability, caching and indexes get matched together there is a complexity explosion and it doesn't (normally, anyhow) make sense to implement a domain-specific DB (call is a DSD?). But, arou…
What is exactly hard about sql? Every dev imho should know it. And sql syntax is good and proven too be long lasting. Maybe investing some time in actually learning it instead of bashing it will help you further.
- No non-nullable types (at the expression level). No way to express e.g. normal boolean logic
- No real data structures (at the expression level), unless you count rows, which are not first-class values. Even collections aren't first-class
- Very awkward control flow constructs. E.g. look at how you write recursive queries. Even if/else is weird. It's a classical Turing Tarpit: everything is possible but nothing is easy
- Absurdly complex grammar. Something like 200+ keywords. Bizarre and inconsistent quoting rules
- Weird rules about where expressions can be used, and where you have to put variables. Often if you want to extract out a common subexpression and reuse it you have to completely restructure your statement.
- Missing basic functionality, e.g. no string concatenation operator (except in some nonstandard dialects)
- No libraries. No standard way of reusing code. No unit testing framework, which means in practice most projects have no testing.
It's a terrible language by any reasonable standard. Its closest cousin is COBOL, and that's honestly less awful to write.