Raw SQL is not very composable, while Korma emphasizes composability on the second paragraph of the page.

And composability lets you create business DSLs and macros on top of that. I've used this to good effect with Rails' Arel, but since it is still Ruby, you can't go as far unless you're willing to parse the Ruby into something more legible, like S-expressions.

It does make sense to be able to define business/application logic as reusable query components.

For example, if your PERSON entity has TITLE, FIRST_NAME and LAST_NAME fields, that little bit of logic that concatenates them together in the right way to form a full name is something that is useful to define. Likewise, setting up a join of tables that is used many times in your application is something that Korma will let you do.

Even though these components may be implementable on the database side (as user defined functions or views), it may not always be possible (or desirable) to do that way.

I spend much of my time in the database, legacy and greenfield, and I would love a better DSL than SQL, something that ran directly in the database itself and targeted the planner/optimizer rather than just emitting more SQL. I would like to be able to pass a WHERE clause to a function, or a SELECT statement to a procedure, not just simple ints, or strings to be exec'd.

In this case, an embedded DSL brings all the goodies of Lisp's code-as-data to SQL.