Separate FuturePools keep the caller from having to know anything about the implementation; we wouldn't have to put scary thread-related code in the configuration. On the other hand, reusing a single FuturePool is a little more efficient with cached threadpools because threads can be reused for both indexing and storage. (The efficiency difference is ambiguous with fixed thread pools because fewer threads get created total at the expense of less parallel computation.) In principle, we could get the benefit of both approaches by using an optional parameter that spawns a new FuturePool if no existing pool was passed, and not using it by default (so that people who know what they're doing could use the more efficient approach and people who don't wouldn't be intimidated by seeing threads in their config). Thoughts?

I also just realized that cached thread pools are self-closing (or at least, the threads are) and fixed thread pools don't seem to be. The code right now doesn't close the thread pools. I think it should be okay to close them when the database connection is closed since after that the threads wouldn't be able to do anything interesting anyway, but I'm not really sure what is supposed to happen if e.g. AnormStorage is closed synchronously while writes are occurring in a separate thread...