The issue I have here is that I think at their core, both solve the same problem in nearly the same way. The use of SQL-like syntax versus CQLs more mathematica

The issue I have here is that I think at their core, both solve the same problem in nearly the same way. The use of SQL-like syntax versus CQLs more mathematical terms like project is a valid point, but ultimately doesn't at all change the abstraction. SQL itself is largely just a different syntax for relational calculus. I suppose I'm seeing another Lein vs. Cake situation here and feel that it would be nice if efforts were concentrated. Both CQL and Korma need to make some changes to make fragments composable. The only really interesting difference is the issue of subselects and why CQL generates a lot of them in it's translation to SQL. From a theoretical standpoint, subselects can often be rewritten as joins and many databases do this as part of their query compilation process. It doesn't seem like an unfixable problem. For example: (-> (select* "user") (fields :id :username) (where {:email [like "*@gmail.com"]}))) This can be written in CQL (I think): (def user (table db :user)) (-> (select user) (project [:id :username]) (where (like :email "*@gmail.com"))) So the difference is only renaming project to fields? Niether keywords are in SQL. Other syntax differences like limit instead of take are similarly minor. It almost seems like you could just def some aliases and the two libraries would read nearly the same. It really feels like a part of Korma and ClojureQL should be the same library with the entities and has-one type relations built on top of it. Choice of keywords shouldn't be a massive stumbling block to collaboration, although the subselect problem in CQL should certainly be addressed. I do hear what you are saying, but I can't actually see it in the implementation. Edit: I don't mean to be overly critical. :) It's just that the two libraries seem so very similar to me!