That sounds like the right decision. You don't want large collections in memory, let alone to add dependency tracking to them.
You can bind a data grid to a paged collection view, and let it manage paging, sorting, and caching. You won't get the advantages of a view model layer when you do this, so just show actual data columns in the data grid.
When the user selects an item from the grid, you can load the record into a business object with Independent sentries. This would back the view model for the details pane. You'll have to handle the right events to save changes to this business object back
to the database.
Another alternative is to switch your UI to a search metaphor. Instead of showing the user thousands of rows, guide them through a search. Only bring at most 100 results back from any particular query, and ask the user to narrow it further. Maybe you can
show them tags with counts to help them apply new filters. This would all be driven from the database, so again Update Controls only enters the picture when you have screen-sized data.
In either case, the answer is to use in-memory business objects with Independent sentries only for data that the user can reasonably navigate. For large data sets, keep it in the database.