The language isn't particularly compositional (why both HAVING and WHERE? why must we repeat SELECT column expressions in HAVING, ORDER BY etc?), and the "natur

The language isn't particularly compositional (why both HAVING and WHERE? why must we repeat SELECT column expressions in HAVING, ORDER BY etc?), and the "natural" grammar means it usually isn't very discoverable in an editor. The grammar puts operations out of order (SELECT should be last! And usable multiple times, to simplify expressions!), and multi-word clauses with contextual meaning are harder to complete effectively in a syntax-aware editor. SQL is also a bit of a two-edged sword. You can do very powerful things with it that are infeasible in normal code, because they'd require round-tripping enormous quantities of data. OTOH it's easy to write code that performs and scales dreadfully, which will normally have knock-on effects across the whole production system, which is pretty scary. There are usually multiple ways of writing what is semantically the same query, that perform quite differently, depending on how smart your target planner is. Despite the language being nominally declarative, you still need to keep in mind potential execution plans as you write the code, and verify on reasonably sized data sets that the plan you expected, or one better than it, was selected. It's been my experience that most developers don't have cost model estimation baked into their brains, so the more advanced cost estimation you need to do with a declarative language is even rarer.