The potential problem is performance and you don't have a performance problem, yet. There are many things you can do depending on the database of choice to handle this in solution #1: indexing, hardware, caching, etc. This all depends on how frequently the user needs to get a current unread message count. Many of these choices don't require custom coding on the app side, so you can implement them with a code change or very little. Makes it easier to grow with the app.
Once a user connects/logs in, getting the count from the database once is not that bad. Will your app maintain a constantly updating list of messages like email? Getting an unread count from here doesn't require another trip to the database and to get new messages is going to take a db trip anyway.
Taking a trip to the db every time a message is read to flag the IsRead? field is enough without a recalculation of another field.
With solution #2 (keeping a count in a field/on disk), will you need a routine to periodically rebuild/recalc this field when there is a problem? And there are always problems. Are you going to wrap all of this in a transaction? Each time someone sends someone else a message it could fail because it can't update the receiving user's UnreadCount due to a lock of the User table? Or are you going to create a separate table for this field?