Datastore sent too frequently on datastore2

im not quite sure , is this ok ?

this part here needs to be set when data is loaded or changed not right before saving

you should then use this value to save the data since it should be already up to date

thats what the playerdata table in this script is used for

Also you need a while loop that goes through and saves/updates the data that has changed on the player ever minute or so incase of server crash that way your not trying to save all the data when server is shutting down and you also won’t timeout the datastores

the loop , i understand but the local playerData = {} , uhhh i dont understand . sorry im not pure english so its kinda hard to understand

Here is your top datastore script with a setup like i was explaining
all you have to do now is just change the money.value with server scripts and it will autosave and update
this has the loop at bottom to autosave and also catches and updates the data with Money.Value changes

you should be able to code your car script to work the same but I would suggest only having one main save script control most of your player data

Also did this quick and haven’t tested but I think I have most everything right
I commented in it so you can tell and learn what its there for

local DataStoreService = game:GetService("DataStoreService")
local DataStore = DataStoreService:GetDataStore("DataSaver001")
local Players = game:GetService("Players")

local playerData = {}  -- holds the players current data on server
local playerDataChanged = {}  -- holds players that need saved
local timeBetweenSaves = 60  -- 1 minute between save you can adjust this how you like

function savePlayerData(player)
	if not playerDataChanged[Player.UserId] then return end  -- no need to save the data it hasnt changed
	local success, error = pcall(function()
		DataStore:SetAsync(player.UserId.."-Money", playerData[player.UserId])  -- this saves the current data saved in the playerdata table
		print(player.Name .. "'s money data saved. Current money: " .. playerData[player.UserId])
	if success then  -- since it was success and their data is up to date in the datastore you wnat to remove them from changed table
		playerDataChanged[player.UserId] = nil 
	if not success then
		warn("Error while saving Money data: " .. error)

function loadPlayerData(player)
	local success, data = pcall(function()
		return DataStore:GetAsync(player.UserId.."-Money")

	if success then
		data = data or 3000
		player.leaderstats.Money.Value = data
		playerData[player.UserId] = data -- this is where it is set
		-- this will update the playerdata table when the value is changed on the server 
		-- this allows any server scripts to add or remove money and it will instantly update to the playerdata table
			playerData[player.UserId] = player.leaderstats.Money.Value
			playerDataChanged[player.UserId] = player    -- this will set that the players data has been change and needs saved on the next loop
		print(player.Name .. " has " .. data .. " money.")
		warn("Error while loading Money data: " .. data)

	local leaderstats ="Folder")
	leaderstats.Name = "leaderstats"
	leaderstats.Parent = player

	local Money ="IntValue")
	Money.Name = "Money"
	Money.Parent = leaderstats


	playerData[player.UserId] = nil   -- this nils out both the data and the changed when player leaves
	playerDataChanged[player.UserId] = nil


while task.wait(timeBetweenSaves) do  -- waits 1 minute and saves any players data that has changed
	for userid, player in pairs(playerDataChanged) do  -- this goes through and saves any data that has changed since last loop

why dont u try using profileservice? its an alternative to datastore2

can it load old data ? never heard of em

Hello, I see your problem, I will try to explain as clearly as I possibly can :slight_smile:.

The error message you’re receiving from Roblox’s datastore is informing you that you’re hitting the datastore limit for the rate at which you can send requests. This limit is in place to ensure that the data store remains available and responsive for all developers.

There are different types of limits placed on data store requests. They include:

  • Per-minute limits: Every game server is allowed to make a certain number of datastore requests per minute.
  • Per-server limits: Each individual server instance is allowed to make a certain number of requests per minute.
  • Queue limit: If your game is making too many requests too fast and the system can’t process them in time, they get added to a queue. If this queue fills up, any additional requests will be dropped, which is what the error message is warning about.

To avoid these limits, you should reduce the number of requests you’re making to the datastore. There are a few strategies you can use:

  1. Batching: Instead of making many small requests, try to group them together into larger requests. For example, in your case, you can save multiple pieces of player data in one request instead of making individual requests for each piece of data.
  2. Rate limiting: Make sure you’re not making too many requests in a short amount of time. If necessary, add delays between your requests to avoid hitting the limit.
  3. Caching: Keep a local copy of data and only write to the datastore when necessary. For example, you can save a player’s data when they leave the game, instead of saving it every time a small change is made.

Looking at your code, it appears that you’re correctly saving player data when they leave the game (PlayerRemoving event), but you should be careful with the frequency of datastore requests in the money.Changed event.

The money.Changed event is triggered every time the player’s money value changes, which can potentially be very often. Instead of directly setting the datastore in this event, consider implementing a caching system where you keep track of changes and save them after a certain time interval or when the player leaves the game.

Here’s an example of how you can implement this:

local moneyCache = {}

    moneyCache[player.UserId] = create_table(player)

    local player_stats = moneyCache[player.UserId] or create_table(player)
    local motor_stats = CreateTable(player)
    local MotorStats = newDataStore("VehicleData", player)
    local MoneyStats = newDataStore("MoneyData1", player)
    player.leaderstats.Money.Value = player_stats.Money
    print("money and motor saved for " .. player.Name)
    moneyCache[player.UserId] = nil

In this modification, money.Changed event just updates the cached data instead of directly saving it to the datastore. When the player leaves the game, the cached data is used to save their stats to the datastore. This should significantly reduce the number of requests your game makes to the datastore and prevent you from hitting the limit.

Thanks! I really appreciated ! so the causes of warning are moneychanged ?

1 Like

Alright thank you for helping me i try it , and im gona make sure it runs well

Alright thanks for the info , later i will try it

1 Like

Yes, the money.Changed event might cause too many DataStore requests if it’s connected to a function that writes data to the DataStore every time the money changes. Since a player’s money can change very often during gameplay (e.g., whenever they earn or spend money), writing to the DataStore every time this happens can easily lead to exceeding the DataStore’s rate limits.

but it happens when tons of player join at the same time , i have played with my friends while game went private but got no kind of warning , when i public-ed it , warning occur . i heard from my friend he said that you dont have to care bout money.changed since it will save anytime it want . idk if its true

The issue you’re facing is indeed a common challenge when designing systems that handle many users concurrently. The sudden spike in player joins can lead to a burst of data-saving attempts, which can overwhelm Roblox’s datastore system.

As for the money.Changed event, your friend is right to a certain extent. However, it does depend on how your game is set up. If you’re saving the player’s money to the datastore every time it changes, this can lead to a large number of datastore requests, especially when many players are interacting with your game at the same time. If many players join your game at once, and they all start earning money quickly, it can cause a large number of datastore write requests.

Here are a few ways to mitigate this problem:

1. Cooldowns or Delays: Implement a delay before saving data. Instead of saving immediately on the money.Changed event, you can start a countdown (say 1 minute), and then save the data after that. If the money changes again during this countdown, reset the timer. This way, you’re only saving at most once per minute, per player.

2. Queueing: If you’re dealing with a lot of requests, you might want to consider implementing a queue system. This can help you manage large numbers of datastore requests by queuing them up and processing them in a controlled manner.

3. Batching: If possible, group several changes together and save them all at once. This can significantly reduce the number of requests made.

Remember to also utilize pcall() when dealing with datastores to catch any errors that may occur, including rate limit errors. If an error does occur, you can retry the request after a delay.

1 Like

Great to hear , i will try it !

1 Like

thats what this loop setup does in this script only saving data that has changed

good luck with all this saving data can be tricky but once you understand its all good

1 Like

I SEE ITS NOT NORMAL DATASTORE PROBLEM , THE PROBLEM IS FROM DATASTORE2 IM SO DUMB . yeah i really wasted my time by spending on old data . and if i gave up willing to use yours

Idk wat to say cause both of u , i fnally managed to fix it :grin: thanks :grin::grin::grin::+1::+1::+1::+1::+1:


yeah datastore2 is not a very good system in terms of not losing data it is very picky on keys etc so if anything is changed or you need to adjust it can cause you to lose data…

I learned this the hard way from a few games I had to migrate off of that system

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.