I built a system on top of yesql* and eventually threw most of it away because it was a lot more trouble than composing queries with honeysql. I prefer honeysql to yesql for the same reason I prefer hiccup to enlive. It's just easier to compose things with native data structures using the full clojure language.

* I even maintain a fork of yesql powering several of my production apps to use that has features that were never merged (such as making it possible to insert maps as jsonb into postgresql by deferring to the underlying jdbc libraries for serialization).

I'll have to give honeysql another look. Superficially it looked like Korma, which turned me off for the exact reason mentioned in yesql's "rationale" section, so I didn't investigate honeysql any further.

You can use it like korma if you want (it has a higher level dsl (but with functions that all return a map)) ala:

    (require '[honeysql.helpers :as sql])
    
    (def query-map (-> (sql/select :*)
                       (sql/from :foo)
                       (sql/where [:= :bar "baz"])
                       (sql/limit 5)))

This works because each of these functions has two arities, the lower one returning a map, and the higher one assoc'ing or merging (there are merge-* functions for building purposes) something into its first argument (which is presumed to be a map).

    (= (sql/from :foo) {:from '(foo)})

This means that if you just need a SQL AST, you have this handy map thing that honeysql can turn into platform-specific sql. But if you just need something quick and dirty, you can use something that looks very similar to korma. There is no ORM functionality, but with a query building toolkit, I haven't really needed it. Since honeysql's helpers are built as functions, I haven't even really needed to dive into the lower map representation much, although it was handy the one time I was translating a higher level query language into sql.