Hello, I've been thinking for quite a while what data should the versions tables store. There are two options: 1) Store only historical data, that is, when a row is changed, insert the old values to the versions table. That way, historical data is in the versions tables, and "current" data is in the normal tables. This is space efficient, as it doesn't store duplicates of the data. However, querying is quite complex - you have to consider data from two sources (so, for retrieving entities that satisfy some conditions, you need effectively two SELECTs - one from the normal tables, one from the versions tables). Joins, for example, would be very hard to implement. 2) Store all data in the versions tables, that is, when a row is changed, insert the new values to the versions table. This is less space efficient, because the "latest" data are duplicated. However, querying is much easier - you only need to use one table. And the query could be much richer, allowing more operations, like a "join at revision N". Currently Envers uses 1), but as I'm writing the query system, I started wondering if 2) wouldn't be better, as memory is cheap, and maybe richer querying capabilities are more important. (Converting data between the two shouldn't be a problem, so if you are currently using Envers, don't worry :) ). What do you think? Which option do you prefer? On the space-saving issue, it's very probable that we'll soon have the possibility to store DIFFs of data only, thanks to Elias. The winning option will be implemented in Envers, so your vote counts a lot :). -- Adam