This seems totally reasonable to me. I was playing around with using Firebase (https://www.firebase.com/) as the datastore for a turn-based multiplayer game on the web and its data policies seemed very well suited.
Essentially, each game was its own document and relevant stats were updated/duplicated on the player documents as well.
There don't seem to be useful relationships here that I'd want to query. Maybe successive game states? But not across different games, right?
Well, I was imagining a situation where you had multiple different pieces in a game, relating to each player and distinct to that game. Maybe like an RTS game or something?
So you might want to query how many pieces a certain player has available, or do a check on who this piece belongs to.
Keep in mind I'm still not saying an actual game, but any problem that had similar data storage and access patterns as a game along these lines would have.
I don't know enough about firebase to confirm whether it is suited to this, but if I had any kind of backend at all, and I had requirements for really quick reponses, i wouldn't be comfortable adding the extra hop to a hosted service onto each call.
Essentially, each game was its own document and relevant stats were updated/duplicated on the player documents as well.
There don't seem to be useful relationships here that I'd want to query. Maybe successive game states? But not across different games, right?