I’ve seen a few posts regarding the unreliability of regular data stores, and I’ve never created a game that generated enough players to get viable data. Because of this, beyond some arbitrary charts, I don’t know what to expect.
So, in your experience, how reliable are regular data stores, assuming you use good scripting practices? (e.g., Not overwriting unloaded player data, not saving nil, etc.)
I’m asking about regular data stores specifically. Supposedly, Roblox dislikes the use of DataStore2, even if they won’t punish you for using it.
I have never had an issue with it but I never tend to push datastores to their limits, so it makes sense that they never bug out on me. They seem pretty fine though
I have tried to make a simulator before, but the datastores would queue up and end up dropping requests. If you make your game too big for them, they will start failing and people will lose progress.
DataStore2 is basically like a very small pistol, It is easy to use and gets the job done. It is not powerful but it is easy to use and if you mess up you only lose a finger.
Regular DataStores are a shotgun, They are WAY more powerful and can do WAY more but if you mess up you get your whole head blown off.
Datastores are reliable if you know how to use them. If you do not know how to correctly queue up data as not to fill up the limits then it will fail but if you use it correctly you can do soo much more.
that is not accurate, any size games are able to use datastores. If you manage it poorly and call each players data too much then it will error but if you use it correctlly then it is fine.
So, if I were to script in a way that respected the limits, and uses good data storing practices, I’ll have a lot more capability and a nearly non-existent chance of failure?
no what i was saying was that my game had a lot of data. There were many things i saved with datastores in my game. Eventually they stopped saving as it would try to save a lot and would start dropping requests.
They dont just drop, unless you improperly save data. You should only save it when a player enters and when a player leaves to prevent filling up the queue. Datastores are a shotgun that must be handled carefully or else they will cause a lot of issues.
DataStores are very reliable if you take out the factor of unpredictable failures which seem to be more common nowadays. Other than service disruptions, regular DataStores are very reliable.
There are a lot of discussions and such about the reliability or unreliability of DataStores, but it’s within my belief that they aren’t unreliable. If Roblox follows through with the updates they promised at RDC, then they will have an even higher degree of reliability and even more utility for developers.
Ultimately if you heard this discussion from DS2, then it solves a nonexistent problem. There are plans to natively support what it can do (backups) and presumably better than a Roblox library can. You’re better off using libraries that don’t completely baby you through the process and allow you to extend properly upon the service to resolve real issues, such as ProfileService and session locking (an especially important consideration when systems like trading exist in your game).
You’ll want to do as much as you can with your own libraries and be mindful of the limitations imposed upon their usage. If you work under those limits, you should be gold.
I see, thank you. My use case is primarily saving and loading data for one person (If you remember my post from yesterday), but I’ll check out ProfileService.
Thanks for everyone’s help as well - @sniper74will, @jakebball2019.