I agree that SQL as the lingua franca for talking to relational data stores is not ideal, and that in various ways it could be improved. I personally would star

I agree that SQL as the lingua franca for talking to relational data stores is not ideal, and that in various ways it could be improved. I personally would start out with some of the issues of cosmetic syntax orthogonality, though I realize there are bigger fish to fry. But two things come to mind on reading your comment. 1. For the problem of Object-Relational-Mapping (ORM) which query language is used is not that important. If one accepts that there is one general purpose language for application development and another for managing persistent data, you will be left with a situation where there is a bunch of redundant code to write in whatever query language and application language you have available, and it would be nice to not have to write all that by hand. 2. Over the years, I have encountered many projects (languages) that attempt to address various deficiencies in SQL. I feel like a lot of these projects make life too hard on themselves. Rather than building extensions to existing database engines, they want you to adopt not just their new language, but their whole persistence stack. If I was smarter, and I had a design for a "better SQL", I would try to integrate it into Postgres or some other existing database engine. I guess that's what some of the ORM authors are trying to do, but by compiling their language to SQL supporting all databases at once. But returning to point 1, that seems pretty separate from the issue of Object-Relational-Mapping.