After some time to look into this, I understand why this happens.

First off, Envers looks at all the entity-mappings your application supplies ORM. From these mappings, it determines if any are annotated with @Audited and if so, then special XML mappings are given to ORM after-the-fact. These special mappings are influenced by the envers configuration properties you mentioned, so they'll default to being created in the configured schema/catalog accordingly.

Secondly, if you don't supply your own annotated @RevisionEntity class, Envers will build a special XML mapping that represents that for itself, supplying this to ORM after-the-fact- just like the audited entity mappings. Much like the audited entity mappings, these are also influenced by the configuration properties.

But what you've described, you're supply an annotated @Entity with the @RevisionEntity annotation. This means that ORM actually is responsible for creating and managing the mapping data, not Envers. So it's important that you supply that mapping with all the pertinent information, including duplicating the schema/catalog assignment values. Envers instead in this use case, looks up the entity-mapping and then builds some internal structures that know how to use a pre-existing entity mapping for storing that information rather than building one itself.

That said I'll see if we can influence the values in some way. What I need to see is if this is even possible after-the-fact since the relational model for that entity-mapping has been built before Envers reaches its integration point. I'm not sure if that data can be mutated safely is the concern.