The linked page has excellent advice (it says: create the "handler" function as a closure over [the db, etc.etc.]) although in Pedestal you want to create interceptors (not handlers) in a closure with the db, etc.etc.. The Pedestal "context map" is something else. It carries outputs of one interceptor for use as inputs to other interceptors... enabling interceptors to reason collectively. See Pedestal docs at http://pedestal.io/pedestal/0.7/guides/what-is-an-interceptor.html#_sharing_information_between_phases . Just add your db as a parameter to the timing-interceptor example function and you're all set.

Thank you very much. I was able to make it through, I was missing somehow that "the thing" of pedestal were interceptors. By adding an interceptor including the :db (and others) elements to the context it was then propagated!

Something new in 0.7 is the ability to specify an initial context as part of the service map; this is where you’ll inject dependencies such as :db, that will be available to all interceptors. This is easier, and microscopically more efficient than, adding an interceptor to inject such dependencies. But I’m also a fan of each handler being a component with its own specific dependencies. That appeals to me for an organizational viewpoint (it lets you get rid of dependencies that aren’t used because you can see if they are used or not much more easily). A component (i.e., from Sierra’s library) can implement IntoInterceptor to expose itself as an interceptor. I have some plans to do some examples in the documentation, a component-oriented one using the IntoInterceptor trick would be a good one.

Amazing @U04VDKC4G. As soon as you have some examples, I will be very glad to take a look. Thanks for the details as well!