A few questions on object database design

I've been trying to model a database that stores data in an MMORPG. With ObjectDB, a lot of things are easier to perform. Intuitively, I created an entity class called player and stored everything about the player as embeddable classes. However, my colleague questions about this structure, since we would be looking at persisting data from the server every minute or two per player. He has stability issues with the ObjectDB if we are accessing the same table all the time.
I know that ObjectDB outperforms a lot of other conventional table-oriented databases, but I'm wondering whether my colleague has a point here. I mean, there seem to be a lot of info in each character (list of items, skills, account info, statsm etc.)...

However, if I think of making some of the fields in the player class entities, then it seems like we are back to the table-oriented databases' design principles. After all, everything stored in player instances are unique to that player...

So, is it OK to store that much information in one entity class? Moreover, is there a limit on scalability for this design?

There are no strict rules because the optimal design depends on too many factors. Obviously there are advantages and disadvantages in each method.

In many cases using embedded objects improves performance by eliminating the need to persist and retrieve small pieces of data separately. On the other hand, if the entity object becomes too big and it includes a lot of data that is not always needed, it may not be the best solution.

Eventually the only way to know what is better in your specific case is to test several options in a benchmark that represents the activity of your application. Switching between entity classes and embeddable classes is easy, so if you already have tests that check the performance of your application, you should use them to check what is better.