Should a query's follow-up queries vanish into the woodwork, silently and unobtrusively furnishing whatever you need? A work-of-art along such lines was Datomic's Entity API, wherein an entity's member accessors retrieved linked entities, upon the first request for them. The Pull API came later to Datomic.

I don’t really go out of my way to minimize “round trips”, I like being able to break things into functions that make sense and reuse them

typically my query functions take a db as the first parameter, so they will have the same basis and xt/open-db should speed up multiple requests as per docs, but I haven’t done any measurements

I don't think it's a bad idea to aim for constructing big monolithic queries, however the performance can be harder to reason about and retain granular control over. That said, all database software should inherently attempt to gradually improve query planning (e.g. using data statistics) and execution (e.g. using data parallelism) over time, such that big monolithic queries could eventually run more efficiently than even the most carefully hand-optimised Clojure - we're certainly moving the XT engine in that direction over time. The advice to use open-db (per thread) is definitely the best way to regain the caching benefits of doing everything in a monolithic query.