There are two places in the current persistence setup where I think we can offer more customization for advanced users. All of this are just first ideas and up for discussion. If the dev team doesn't like the (use case value)/(maintenance workload) ratio, I'd be fine with not doing this.

1. Edit: We're dropping insert/replace_data see Drop BasePersistence.insert/replace_bot #2882 .

   Original comment:
   We currently pass all data that goes through the persistence setup through replace/insert_bot. While this is the safest way to make sure no Bot instance gets serialized, it can also introduce some overhead which could get noticable when you have large, nested data structures in your chat/bot/user_data or are handling many updates. Adanced users will know where in their data they have bot instances that should get replaced. So we could offer settings like replace_bots_in_chat/bot/user_data (defaulting to True) and only call replace/insert_data when necessary.

   One should note that we'd have to re-indroduce deepcopy into the built-in persistence classes (depending on the replace_bots_in_* settings, that is). See Customize context #2262 (comment)

2. Adjust calling of update_persistence #2285 already made an effort to reduce the calls of Dispatcher.update_persistence. Still, updating after every update (or even handler call in case you're using run_async) might be unecessary, especially when you're getting updates frequently. Similarly to PicklePersistence.on_flush which allows users to control how often PP writes to file, we would add a flag telling Dispatcher to never automatically call Dispatcher.update_persistence at runtime (only on shutdown). Then users can call Dispatcher.update_persistence manually to their liking.