While web applications tend to store everything in the database immediately, games work a bit differently.
Any information pertaining to the players currently in the game is stored in the RAM of the gameserver. This is not just to keep load off of the backend database, but also for performance reasons. Games require very low latency and do a lot of number crunching. Delegating all that to the database would result in unacceptable response times.
And then there is a lot of information which really does not need persisting. Like the positions of monsters, for example. When a server reboots, then nobody will care that the monsters don't spawn in the exact same locations as they were when the server went down.
The information the game does need to persist, mostly the state of the player-characters, usually does not get persisted to the backend database in real-time. Usually it only gets persisted when the client disconnects, the server goes offline or at regular intervals (to not lose too much game-state in case of a server crash).
And because character-states are usually persisted and restored in an all-or-nothing manner, I would argue that it is questionable that there is any benefit to properly normalize all the data of the character gamestate. So instead of making different database tables for character stats, character inventories, character quest states etc. it can make sense to just store all the information about each character as a BLOB. The drawback is that BLOBs are far harder to analyze and data-mine. But you can solve that by importing all that data into a properly normalized secondary database used only for analytics. That data doesn't need to be perfectly up-to-date, so you can do that as a daily job which runs during the time where you have the least players online. And then the analytics team can do whatever they want with their analytics database without affecting the actual game.