I just end up throwing the maps away, and I'd like to get rid of that overhead.

You can use :raw, but you also have to consider what the underlying library is returning. The 4th argument of your hugsql-defined function takes options and sends them along to the underlying library. In clojure.java.jdbc, you could send along {:as-arrays? true} for a result like [["id"] [1] [2] [3]] . I suspect there is a similar option for next.jdbc.

I think it's {:builder-fn next.jdbc.result-set/as-unqualified-lower-arrays} per: https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.2.772/doc/migration-from-clojure-java-jdbc#rows-and-result-sets

It occurs to me that the arrays returned here aren't much better than the maps, since you still have to take the first item (columns) off and then the first of each vector. So, it's either (flatten (rest x)) for this return value, or (map :id x) for the maps.

oh this is great. Somehow I missed that there are extra arities to the hugsql functions. You're right, though, array of arrays versus array of maps isn't much different but I'll see what I could do to get array of string.

in the end it's probably fine for the use I'm working on right now, but this is great to know about in future.