I’m a bit surprised that no one asked this question, so I might as well ask it for some good ol’ fashioned debate.
Preface, skip if you don’t care: I am working on a game which is in a pre-alpha state, and of course it uses DataStores to save player data (specifically loleris’ ProfileService but that isn’t important to this). Naturally since I’m in the pre-alpha state, I want to see how I’m able to improve my code considerably before our first alpha.
One of my ideas was to take my single Player Information DataStore I’m calling on and split it up, such as a DataStore for individualized player progression data (Money, experience, vehicles, house items), another one for player-made team data (metadata, players, progression, etc.) and another one for moderation (who’s banned, who’s muted, etc.) But, that raised me to wonder if that would be an efficient way of doing what I want to do. But also, at the same time, I realize that others might have this question, either now or later down the line.
So, with that said, what would be better? Not just in my case, but overall. Would one DataStore or multiple DataStores be better?
I am not asking this question in specific to my game or specifically my use case. Instead, I’m asking it as an open-ended question for different use cases. I’ve just so happened to place my struggle in this post just to have some place to start.
I’m very interested to hear what people will theorize, alongside what other people have already done in their games and what they have noticed with their approach.
Edit: Moved over to Game Design Support due to the nature of how I worded things / how the responses came out.
I have multiple DataStores with ProfileService as well. There is nothing bad that happens if you use multiple datastore if you make sure everything is done right.
I had this issue with my game, it ended up being a pain. I recommend you store everything in 1 datastore via a table. It’s more cleaner and can cause less lag. The less datastores the better
Having different datastores only becomes a problem when you are using quite a lot of different ones for player data as each datastore will need to use up a single get request per player, which can really stack up. It also become a nightmare with GDPR as every datastore needs to have the player’s data removed.
Using different datastores does allow you to store more data however, as you are not locked to the 4 MB limit per-key.
Just use one data store. There’s no reason not to. Having more than one just uses up more resources and doesn’t benefit you, unless you are using ordered data stores.
If you’re hitting this limit, I think you need to be re-working the way you store data.
OrderedDataStore is required for any kind of leaderboard, and its the only reason you’d ever be using OrderedDataStore.
To answer the original question, always put everything into a table in 1 datastore. Using multiple datastores will just hit datastore limits faster, and use more resources. This is of course excluding any leaderboards, you need multiple OrderedDataStores for leaderboards.
I would probably only create multiple datastores if the data being stored was totally unrelated. I.e. one datastore is for player data and another datastore is tracking persistent cross-server data about the game’s status or environment.
If you manually implement datastores, you can use scopes to get more keys and in turn store more data in the same datastore. While there is a key limit, I am not aware of any scope limits. (Scopes are still a thing right??)
Also, under Roblox’s Data Store article in the “best practices” section, using less data stores is the very first thing:
Best Practices
The following guidelines will help you manage your data more efficiently and take advantage of future improvements.
Create Fewer Data Stores
Data stores behave similarly to tables in databases. Minimize the number of data stores in an experience and put related data in each data store. This approach allows you to configure each data store individually (versioning and indexing/querying) to improve the service’s efficiency to operate the data; as more features become available, this approach also allows you to more easily manage data stores.
That’s a pretty big limit. Considering you’re only saving strings/numbers/tables. These are only VERY VERY few bytes. You can easily store billions of data before reaching this limit. If you’re reaching it quickly, then you need to rethink how you save data.