One other small downside of smaller Models that I forgot to mention in my original post is that they might lead to slightly more complex application code as each Model will correspond to a different object in the app code instead of a single unified object. For instance if your app wanted single concept of a “profile” but it was represented as 3 underlying ComposeDB models (ProfileName, ProfilePicture, and ProfileAddress, for example), each underlying Model would correspond to a separate object in the corresponding application code.
This could of course be mitigated with a simple profile abstraction that unifies all the smaller profile pieces. Such an abstraction, however, would need to think about how to handle updates to the profile that modify fields belonging to different underlying models, and the fact that those updates are not atomic and could fail independently.
FYI @dysbulic