Louis Davidson walks through some of the properties of rowversion data types:
For years, I had thought (and was probably taught in SQL.AlongTimeAgoInAPlaceFarFarAway) that the timestamp column (well before rowversion was a thing,) was not guaranteed to be an ever increasing value. But this is not the case.
In BOL (https://docs.microsoft.com/en-us/sql/t-sql/data-types/rowversion-transact-sql) it states:
“The rowversion data type is just an incrementing number…”This makes it useful for determining rows that have changed, because it it automatic and the user cannot override the value in the column. However, there is a major concern when you use rowversions, and that is what happens when you change the structure of the table, and expect the consumer to see that change. The problem is that when you change the structure of the table, the rowversion will not be set (except when adding a new rowversion column.)
I’m not much of a fan of rowversion and tend not to use it, but my biases don’t have to be yours.