If my vote counts at all, I’d be fine with truncating this data as a part of this conversion process (if implemented). I can only keep the data for like 24h right now anyways due to performance/sizing anyways - so i’d imagine most larger environments are similar and not keeping this data very long anyways, so not a huge loss.
Hey @ekohl
I tried “implementing” this once. I setup the exact pattern(s) in the example and ran a code import, and it saw no changes.
I “guessed” I expected to see it trying to REMOVE all of the item(s) for which the pattern matched (of which we had plenty). But i can also understand why it might not implicitly remove, and only prevent adding additional pattern match(es).
Might there be a known way to get it to “remove” pattern matched classes, as I’d also want to cut down on my imported classes list, so that the /classes endpoint started loading in a reasonable amount of time again 
We separated our Config Management to AnsibleTower - so Foreman and Ansible can scale independently.
We are looking into Patroni for Postgres HA across datacenter.
Also leveraging multiple Foreman instances against a common Postgres as described here: Foreman :: Journey to High Availability. It allows us to segment some users to a a Foreman instance for a particular high volume builds