Easy Datastore - new and easy datastore module

Easy Datastore

Easy Datastore, the new and superior datastore module

I know the pain :face_with_symbols_over_mouth::sob:!

Datastore modules can be complex, tricky, and time-consuming! Remember all those times you went to documentation-long websites? All those hour-long YouTube tutorials? I also hate that! Let’s stop this nonsense!

SOOOO easy! :blush:

Easy Datastore is designed with extreme ease! No more long documentation! only 3 lines of code:


Improve script clarity and reduce the amount of effort you need to achieve simple functionality.

What about alternatives? :bar_chart::x:

Alternative data modules such as

  • Profile Service
  • Datastore 2
  • etc

Not only are these alternates more complex, but they are actually less optimized too! For example, ProfileService and DataStore 2 have an inferior autosaving system. Constantly autosaving is a bad practice, and Easy Datastore has the Module.save() function to align with best practices.


Setting up your data is clear, quick, secure, and easy! Let’s add some basic currencies to my datastore!

  1. Simply add your currencies to the data folder!


  1. Give them the attribute “value” with the type of whatever you want this datastore to store!


  1. Since there is no attribute for table, if you want to use a table, set the value to the string “table.”


  1. If you want a dictionary, simply parent the folders inside of each other:


Screenshot 2024-02-28 224932

Get() value of coins!

local module = require (script.Parent.economyModule)

local coinCount = module.get(plr, "Coins") -- 0

Set() value of coins!

local module = require(script.Parent.economyModule)

module.set(plr, "Coins", 10) 
module.get(plr, "Coin") -- 10

save() is recommended, but optional autosaving.

  • You should call the module.save() after major events such as leveling up!
local module = require(script.Parent.economyModule)

-- Player levels up here.

Easy Datastore is designed to be extremely robust, despite its simple appearance. Here are the main attributes of Easy Datastore that ensure data.

  1. Cache Loading
    It stops malicious users from slowing down your servers. When a user leaves your game and joins quickly afterward, it will load their data without having to make a datastore call. This prevents attacks and keeps your game efficient!
  2. Error handling
    The module manages any errors through a series of attempts. By default, the module will repeat calling for the data five times. You can adjust this inside the data script.
  3. Efficient data management
    The module stores all data within the same script that saves it. Any sets you call are stored during runtime and saved only when they leave the game. This allows for quick and efficient data saving as it doesn’t have to retrieve the data from external sources.
  4. Anti-data corruption
    Before saving player data, the module checks if the data it’s about to save is inaccurate through updateAsync. The data stores the timer when players first join your game and compares this time with the returned updateAsync values to ensure that you are not overriding existing data with less data.
  5. data compression
    The module utilizes HttpsService:JSONDecode and HttpsService:JSONEncode to save space within your datastores. When data is encoded, it generally takes up less storage, allowing for a more robust system.
  6. Bind to close
    The module utilizes bindtoclose() to save data in the event of a server structure.
  7. SUPER autosaving
    Easy Datastore utilizes an innovative mechanic for autosaving in your game! Most datastore modules use bad practices, such as constant autosaving! Easy Datastore only autosaves when you, as a developer, think it should!
  8. Data recovery during run time
    Whenever Easy Datastore autosaves, it not only secures your players data in the event of a crash but also fixes corruption or outdated information during runtime! This means that when players are experiencing data issues, the module is so robust that it is able to handle it itself without requiring the player to rejoin, like the competition.

Screenshot 2024-02-28 224522

Upgrade your datastores! Download NOW!


The problems I see with this module:

  • Dataloss when data failed to load 5 times in a row. It shouldn’t save player’s data if it failed.
  • Typo: module.devide
  • Unnecessary functions, such as boosts.
  • Inability to save formats other than number, making most of features impossible to build using it.
  • Weird structure in general, utilizing bindables for no reason.
  • module.get doesn’t even return anything.

these issues have been fixed, thanks!

1 Like

Good, but I don’t believe in reinventing the wheel unless there is a reason to. ProfileService works fine for me.


This can be replaced with threading for a more simple structure, just a single task.spawn. In your case, you don’t even need it since you only utilize events.

In my opinion, boosts should be scripted by devs whenever it’s needed, in your case it just affects the “efficient” design, causing more calls when not utilized by developers.

Just noticed that.


Again, thanks! I fixed the mentioned issues!

1 Like

Simply combine those 2 scripts into 1.


Okay I combined them! Thank you for the feedback!

1 Like

I have gone ahead and combined the script with the module.

The module no longer uses any bindable events or functions to operate.

There is a remote event still however for running code on the client when a currency is updated (like a coin display)

All of the functions seem to work well too. let me know if you find anything else

1 Like

actually, no this is incorrect.

The logic inside of the script, such as the joined even and leave event should not be placed inside of the module script. This is because the module script is meant for functions, not handling events. so you are wrong, and the original approach was correct.

1 Like

just use LoadNumber and SaveNumber /s

jokes aside using the raw datastore api is the best thing to do in most cases

1 Like

Personally, being a bit biased as I am the creator, I disagree with this statement due to the simplified nature of Easy Datastore and its emphasis on reliability. Basic datastores cannot achieve the same affect as Easy Datastore without going out of your way to support the best practices.

base datastores dont lose data unless roblox’s servers lose data
what happens is people dont do proper error handling and wipe datastores if they return nil for some reason instead of doing the right thing of preventing further datastore reads and writes

Let me know if you guys want me to make a plugin the helps you configurate the plugin

Module needs a lot of work before anyone uses it seriously.

Some criticism, some of it copied from here (but is still applicable to this module):

  1. You don’t check if the data successfully loaded before saving it in PlayerRemoving. This means if the player joins the game and their data fails to load then there’s a chance it will save when they leave.

I verified this by setting my coins to 300 and then leaving to save it. Then I added an error inside of your PlayerAdded function in the pcall containing GetAsync. Afterward, I joined the game, loaded 0 coins (default amount), and left the game, which overwrote my data. My coins were still 0 even after I removed the error.

  1. There’s no autosaving, if the server crashes then players will lose their data. BindToClose is not sufficient in the case of a hard reset.
  2. There are random task.wait(n) lines added throughout the script. These don’t serve any purpose except to make the module slower.
  3. There are a lot of code smells here, particularly several loops that wait for some value, i.e:
repeat task.wait(.1) until serverPlayersData[plr.UserId]
repeat task.wait() until serverPlayersData[plr.UserId]
  1. module.devide is spelled incorrectly, it should be module.divide
  2. All functions should be properly documented as this is a community resource. Additionally, types should be added to all parameters.

Thank you for the feedback. I will be exploring the playeradded error handling soon.

  1. Purpose: waits for the player to be fully loaded into the module. I am going to improve this system by canceling the wait after a certain amount of tries
repeat task.wait() until serverPlayersData[plr.UserId]
  1. Autosaving: Instead ot implementing autosaving, i plan to make a function called module.save() which is the developers responsibiliy to call after major events. Im doing this for multiple purposes:

  2. Priotizes critical data to be saved and important events in contrast to autosaving which is time based

  3. Reduces overall request count, improving game preformance

  4. Adapting better to the game’s needs rather than constant updating

For autosaving, i will batch requests as such:

  1. When a developer saves, start a 1 minute timer
  2. If module.save is called within the 1 minute timer, it wont save but instead it will wait for the 1 minute before authorizing the save.

In responding to other players saving requests, i will create a “line.” Which will go through all the save requests and authorize the oldest request before removing it from the line. There is a delay between each save in the line to ensure that the autosaving abides by roblox’s guidlines well

I have recently added the


Functionality. Please call module.save() whenever you do a major action. This serves as the autosave mechanic.

Please let me know what you think of the updated module

Oh i like how you phrased that! What di you think of this official microsoft endosred module

Just a heads up, this thread is extremely misleading.

Not only are there numerous practices in which should be avoided or aren’t implemented, see the responses above- but this is also just more or less straight lying.

Microsoft does not officially recommend anything in which you have made. You are simply taking an output from microsoft’s artificial intelligence and saying that’s them endorsing and or recommending you.