Should I be using a data module to prevent data loss?

As a developer and beginning scripter (in terms of datastores), I am always looking to improve my code in any ways I can. I have found it easy to improve in almost all areas apart from datastores.

The reasons for that are:

  • Datastores can only be properly tested in a real game with many real players
  • The consequences of a failing datastore are bad; players leave and may not return to your game if they lose their progress and data
  • It’s hard to test a datastore system for potential unseen bugs, or in the case that datastores go down to see if a system will accidentally overwrite existing data.

Thankfully, some very helpful experienced developers have given us access to efficient data modules that prevent problems like data loss (most known to be datastore2).

My question is, is it worth it for me to try and make a datastore system when I cannot properly test it without potentially losing players’ data (that they may have spent robux on), or should I not bother with making datastore systems myself and just use a data module instead, like datastore2 (as an example)?

I really want to be able to improve my scripting but it’s really daunting to do anything with datastores since I don’t want to lose data in the process because of an unforeseen bug. And these data modules seem so complex compared to wiki examples (like x50 larger) that it makes it feel as if the chance of losing data with simple pcall error handling is pretty high!


1 Like

It depends on your application?

Does Datastore2 actually fulfil the needs of your game? Do you really need to save multiple copies of the dataset?

Imo, having looked at Datastore2 and the newer ProfileService, I would go for ProfileService. However, this again, depends on your application - does ProfileService fulfil the requirements of your project?

Do you require something that neither of these fulfil, or just want to make something yourself so you (1) learn and (2) know the ins and outs of it? Then make it yourself.

The reason the wiki examples are so short is that they don’t include functionality like serialising/deserialising, atomic purchases, saving when you exit the game, saving at n seconds interval, locking/unlocking data when saving, tracking DataStore calls and/or saving multiple datasets per user.

I have previously used datastore 2 but have recently created my own to handle compression/decompression of data spanning multiple datasets - I only made my own because the others weren’t fit for this purpose.

1 Like

Datastore2 and ProfileService both seem like they would fulfil the needs of my game

I want to be able to know how my datastore system works and would like to make it myself but don’t want to deal with the potential possibility of data loss because I miss a little thing while developing it. Which I guess would mean I should use a datastore module but I don’t want to be limited my whole time developing on Roblox to using these modules because of fear with making them myself

I don’t have an inventory or economy system in my game to which I think I’d require session locking or any of the advanced features, my only need is to save a table of data for each player. I think I’d only use autosaving as a precaution if, when players left, the datastore call would fail.

These datastore modules fulfil my needs, but pretty much I’m uncertain whether I accept that it’s too risky for me to make my own datastore system or whether I should actually try to make one regardless of the consequences

Have you even tried this plugin? It seems very interesting for debugging.

1 Like

So, the benefit to both ProfileService and Datastore2 is that they’re both open source on Github. So you can read through their scripts and determine how they function, and what kind of trickery they do to ensure that they have minimal data loss.

I understand what you mean about the concern over not being able to test it thoroughly via Studio but in actuality you can test it pretty well. If you ‘Test Server’ on studio, and spawn in 2 - 4 players, you can test features of the datastore pretty well e.g. atomic purchases, saving at intervals, starting / ending sessions and so forth. If your code works well in these tests and you account for GET/SET per minute limitations of the datastore (as well as the cooldowns), your code will scale fine. Testing how well it works over multiple places within one game is a little trickier but is achievable through the debug panel when playing a game - you would, however, need another user and/or another laptop to test it with you (this may actually be possible to do via studio, I can’t remember how studio deals with teleporting - someone else may be able to chime in).

If you really want to learn, I’d say go for it. I’m assuming your game isn’t finished and/or popular as of yet, so you have time to test its scalability and find bugs. If you’re worried about data loss in the meantime, look at datastore2’s ability to save copies of the data at different times, and revert it if there’s any data loss while you’re still growing.


Thank you for the advice! I’ll try reviewing ProfileService (couldn’t really wrap my head around how Datastore2 works) and will try out testing my datastore system in studio with the test server feature. You’re right that my game isn’t fully complete, so I do have time to experiment. Thanks again!

@Eternalove_fan32 I recognise the name of the plugin, but have never fully checked it out in depth. I’ll check it out, thanks!

1 Like

Yeah the github for Datastore 2 is cluttered with other dependencies, that’s why it’s a little confusing I think unfortunately. ProfileService is super clean and packed as a library, so it’s far easier to jump into. Highly recommend you do read Datastore 2’s method of saving multiple copies though but I wouldn’t recommend using it unless absolutely necessary.

1 Like