Oc_circle_ tables bloated

We have a test instance (version 23.0.0) connected to an LDAP with about 20000 users, but only 5 or 6 active filesharing users. I see the oc_circles tables becoming huge, oc_circles_event about 4.7 GB oc_circles_member(ship) 257 and 323 MB. We have only one circle in use with 8 people.
In the slow logs of the postgres server I see lots of entries related to oc_circles_member table. Also the autovacuum of the oc_circles_event table shows about 3 Millions dead tuples. I am a bit unquiet to activate the app in the production environment because there will be a lot more circles. Has anyone made similar experiences and knows how to avoid huge table sizes and deadlocks? Generaly we would like to use that feature as I think it could be a nice alternative to the groupfolder app.

Yes we had big problems with an even larger Instance.
Before circles was integrated with contacts the database structure was different (I think) and the migration bringing it to the current format ran for nearly half a week with a huge CPU usage.
Ever since we have had a higher CPU usage and not-so-great loading times in the circles section of the contacts app than before the update due to the inefficient database structure.
We managed to get it to a slightly better state through editing the database scheme a bit, but the possibilities are limited.