@steveb8n 1. Make a wrapper namespace for the query namespace and add the instrumentation (timing, cardinality, etc) there. I've seen projects which ship up to honeycomb using a homegrown lib, but the concept is generic. I HIGHLY RECOMMEND creating some notion of trace-id chaining, either via a hierarchy or some other means (e.g. request creates trace-id 123, which is the parent of trace-id 234 created by a query and then a sibling trace-id 345 is made to do some side-effect, all with their own instrumentation numbers that can also be rolled up). It's extremely valuable to see the whole lifecycle of a request, including all the queries and external calls it performs (datomic or otherwise) 2. I think I remember you being on cloud, so another thing to think about is client-cloud vs ions. They each have different tradeoffs but with ions you get the locality advantage. 3. I don't know of any way to include the number of entities scanned other than re-running the query a few times building up the clauses and magically knowing how to replace the :find clause args with a call to count . That being said, if your queries are fairly static (vs dynamically computed from a client request) you could probably build a tool to accomplish this. (d/db-stats db) is your friend here. Also, there is this tool which may be sufficient, or, at least a great starting point for your "auto-tuner". 4. Try to avoid using massive pull-patterns in your :find clauses. Pull's do joins like :where clauses do, but can have subtle and confusing performance semantics, especially when the data cardinalities change out from under you (like in high traffic production environments). 5. Look at some of the new query tools in the latest release such as qseq and :xform in pull. Those are the first 5 off the top of my head, LMK if you want to go deeper on any of them.