It's all a matter of how likely a possibility.
Recipe for disaster? A better recipe would be trying to retrieve all 10 million records to your client in a "static" result set, which won't be "static" anyway because behind the scenes, in the database, the set is changing...so if I want to see what's new/changed, I have to retrieve, again, all 10 million+ records, every time I want to see what changed? No, I don't think so.
You can stop right after "retrieve all 10 million records to your client". You need go no farther than this to call out a truly horrid application and database design. Databases are designed to allow you to limit your results to meaningful data. This is an ETL job, not an interactive query. There are lots of ways to do that.
Databases (at least mature relational databases) are also designed to give you a consistent view of data, regardless of other simultaneous write activity. So changes in the database once a transactionally consistent read started would not show up, unless you forced it.
You can also design your data to address a use case. If you really want to see what data has been changed in a certain amount of time frequently, you can simply add a timestamp column or use a time created on an artificial key. I would refer to the harsh opinion of another poster in this regard - if you "design" your data structures with no thought as to use cases, you deserve what you get.
And please do not take this as a personal attack. I've been toiling in these DBMS fields for a long time, and, to my continual regret, data integrity is frequently not even considered. As I mentioned earlier, if someone consciously makes the decision to accept data which may not be correct, more power to them. If they make a design decision without understanding this, woe is them.