So, where is the revision number and revision timestamp related to the current revision stored or are these values no longer relevant in your proposal?

Due to another requirement (4 eyes principle), we need to put some general metadata to our "BaseEntity" wich is mapped as @MappedSuperclass.
These are for example:

• The creating user (might be a technical one)
• The user which is the last editor
• The user which approved the last change of this entity
• Last editing timestamp (which would be our own revision timestamp)
• Last approval timestamp

Nearly every entity in our entity model which is dynamic data must follow the 4 eyes principle with strict auditing of every change. So we would have the revision timestamp as part of our entity model. The revision ID is not relevant in our case. As our project will include an extensive migration of existing data of a legacy system, were a good part of the data comes from code, business area will provide csv files to bring the initial state to the database. The first revision - again - will have all necessary information included, so we aim for Envers to audit the initial state before the first update of a row is about to be performed to not loose the initial state. When deleting an entity, the current approach serves well for us, but we're getting effort issues if we would be forced to create a huge liquibase changelog file for all the initial revisions. I've tried to generate this changelog with liquibase but wasn't able to do that, since liquibsae db diff on data level is not supported.

Are you assuming your liquibase scripts would only ever INSERT rows and never have a need to UPDATE or DELETE audited entity rows?

Our entity model is separated into two parts: Dynamic data which is expected to grow or change rapidly and masterdata which is expected to stay constant most of the time. Initial db state will come thoroughly through liquibase. Once inserted the dynamic data will only be updated or deleted through the application by the users. So update and delete statements will trigger Envers to audit the changes. Masterdata will only be inserted and might updated without the need of an audit log. The changelog files under version control will serve as a audit log here.