question

Technically, we support MongoDB (via mLabs), DynamoDB, Azure Table Storage, and any other database which has a Web API, as you can call any external web service via Cloud Script using the http API. The MongoDB integration we're working on will allow you to have a greatly simplified way of using MongoDB data tables from Cloud Script, to make this easier, but you could actually use any of those data services today.

Now, on your "seed warehouse", I'm afraid that's not a viable solution. The issue is that you're attempting to use a non-distributed data store in a way that requires distribution. To explain: 

We've designed out core services to take almost all of the work of managing data off your back, so that you can focus on making gameplay features. Our data systems are designed to be massively scalable in the ways that are most effective for two key data types:

1. Data which is highly distributed, and so can be queried by all players. This is what things like Title and Publisher Data are for. They're replicated across multiple shards, allowing you to have millions of players hitting them, without delays. Since you want to store millions of seeds, I would actually recommend considering using our Content system if you'd rather not use an external data table, since that would give you a way to store batches of seeds in files there, and download any of those to the clients as you need them.

2. Data which is not distributed, as it is frequently updated by a player and needs to be always up-to-date. This lets millions of players all have their own custom data spaces, and allows each of them to update their data simultaneously, also without delays. User data and shared group data all fall in this category. While they can be shared by sets of players, a single one isn't meant to be hit by every player in the game, as it's not spread across shards. So, if a thousand players ask for it, their requests are going to stack up - and the physics of this would mean delays. So while the proposed "seed warehouse" isn't really the way to go with this.

What we do for systems where all players are interacting with a data store in a way that requires fast updates plus access by all players is build custom systems that serve that purpose, like leaderboards and matchmaking. But those are purpose-built, so that we can optimize the functionality.

So, I would recommend using the Content service for your "seed warehouse", as that would be the best general-purpose solution. Alternately, if you want to use an external data table system, that option is available, though I would encourage you to do significant scale testing against that, to ensure that you have good solutions for the issues that will occur with large number of players.

Finally though, I wanted to make sure to ask - you are using a code-based pseudo-random number generator, and not relying on the random number generation of the client, correct? I just need to call this out as even with a seed, random number generation isn't guaranteed to be the same across different hardware devices, let alone different platforms.