Sometimes you need to be a little cautious about interpreting the results of comparing databases. You can compare two absolutely identical databases and the compare will usually identify some differences. Or at least that's my experience. When the database compare feature first came out, I did exactly that experiment. Namely, I made an exact copy of my production database and compared the copy against the original. The compare found a very large number of differences between the databases. I have been very suspicious of the database compare feature ever since.
Here is what I think is happening. Before the database compare feature came out, RM had (and still has) a feature called Duplicate Search Merge. It ran against just one database, and it tried to find duplicate people in your database. For example, if you had John Doe born 1877 in Missouri and another John Doe born 12 Mar 1878 in Missouri, the Duplicate Search Merge would suggest that perhaps these two John Does were the same person. You would need to make the final determination yourself but Duplicate Search Merge would be making suggestions of things for you to look at. Well, I tend to suspect that RM's compare database feature is not so much comparing two databases as it is running a Duplicate Search Merge across two databases at the same time. So if you had database A and B which were exact copies of each other, the database compare would suggest you look at each of the John Does in database A vs. each of the John Does in database B. That's four different comparisons. And if there are lots of people in your database with similar names and similar birth dates, the the database compare function can easily identify a lot of false differences in what are really identical databases. Or at least that's the way it seems to me, and I could be wrong.
There are at least two different ways the database compare could have been programmed to work. If both databases are yours and if both databases were created by RM, then this Duplicate Search Merge logic should not be necessary for comparing databases. That's because RM assigns a unique ID to everyone on your database (the unique ID I'm talking about is not visible to the user interface). So, if for example, you were comparing Thursday's version of your database against Sunday's version of your database, RM could easily do exact matches between people in the two databases based the unique ID's and could easily tell you exactly where the differences are between the databases.
In the other way the database compare could be programmed to work, one of the databases could be yours and the other database could have been created by importing a GEDCOM that your cousin sent you. Even if your cousin were using RM, the unique ID's in his or her database would not match yours, and the only thing the database compare could do would be essentially to do a Duplicate Search Merge type of comparison across both databases. Under these circumstances, you could and often would see a lot of false differences.
From observing the behavior of the database compare feature, I think it only works in the Duplicate Search Merge mode, even if both databases are yours and even if both databases are populated with unique ID's that could work across both databases.
The existing database compare feature works pretty well for what it works pretty well for (circular, I know), by which I mean that it works pretty well for comparing your data to your cousin's data. I don't think it works at all well for comparing your Thursday data to your Sunday data. I think the feature needs two improvements. One is that when the unique RM id's exist in both databases, then RM should take advantage of those id's and match based on them. Secondly, if your database has been matched to a tree on ancestry using TreeShare, then RM records a tremendous amount of information about what has been changed and what has not been changed. I think it should be possible to enable this tracking feature even if your database has not been matched to ancestry.
There already is a very weak tracking feature in RM - namely the Date Last Edited feature. But it doesn't track what was changed, only when each person was changed. And even within that constraint, the Date Last Edited feature is unreliable. The Date Last Edited field can be updated even when a person hasn't been changed and it can fail to be updated even when a person has been changed. Therefore, I think it would be totally wonderful if the change tracking in TreeShare became a part of mainstream RM instead of just being a part of TreeShare.