2 ms·
When you never need to work with two different documents at once, but need cheap scale. I once worked on a mobile game which saved player progress by uploading
by golergka 6y ago
When you never need to work with two different documents at once, but need cheap scale. I once worked on a mobile game which saved player progress by uploading JSON to the server — the server never even parsed it, just saved directly to Mongo. And later retrieved it back when the player logged in.
That was the only time when I experienced a Mongo-based system which didn't suffer from any Mongo-induced problems.
- ssijak 6y agoWhy even use a server and mongodb behind it for that when you can straight up save the document to Firestore from the game. No servers, no mongodb maintenence.
- wgjordan 6y agoOne is document-oriented database software while the other is a fully-managed document-oriented database-as-a-service, so not at all a useful comparison. MongoDB offers a fully-managed database-as-a-service as well (Atlas), for what it's worth.
- tpetry 6y agoI swa a talk once from one of the facebook game companies who simply stored the player state in a file. There is nothing more simple! They simply loaded the files content into the memory as long as the player was playing and then serialized to file