Yay! Can’t wait to write In-efficient code
In all seriousness, GG Roblox! I remember my game had issues because of limit before.
39 Likes
Wow this will make things easier although I never encountered it before but I guess I never will:))
36 Likes
Oh my- I was literally just going to search for a feature request that addresses exactly this.
This is an absolute godsend for my projects, thank you Roblox!
I was previously relying on dodgy MemoryStoreService back-ups in order to determine when a key may have been written-to recently as to ensure two servers didn’t queue a request to the same key. This was the only issue I’ve ever had with DatastoreService and has slowed down development time dramatically for me.
However, @dragonknightflies I do have one question, what is the process for if two servers attempt to UpdateAsync at the same time, will the backend reject one request as the value is outdated or will I encounter data loss / will a second request be counted to my quota?
Also, on the topic of removing limits from DatastoreService, any chance we could see the ability to disable GetAsync caching?
34 Likes
This is a pretty awesome change, will help with my development since I would run into the issue at times.
28 Likes
Here’s a post explaining what happens if the parameter passed to UpdateAsync is outdated before the save finishes. The game server that submitted their save request later has its UpdateAsync callback re-evaluated with a new value until it gets to save properly. The new documentation for UpdateAsync also details this.
31 Likes
Yes, I’m well aware that an attempt to ‘fix’ the outdated data will be done however, I’m unsure if such retries count as extra requests to my DataStore limits.
26 Likes
Thank you so much!
Working with Datastores and MemoryStore for cross server session handling was annoyingly frustrating because I can never really trust memorystore to house the most truthful data value, I can now work with my own queue code without being limited for 6 seconds globally.
24 Likes
Interesting update, wasn’t really expecting this one. More than anything I think this will be a nice quality of life update for example if a game as an auto save and someone leaves right after the auto save. Cool none the less
23 Likes
so basically, this has improved data stores but we still need to do “retry” methods? Nice I guess 
23 Likes
This just made my day. Thank you for listening!!!
27 Likes
Unexpected but very welcome QoL change. Thank you!
20 Likes
Such a welcome change!! 
For years this has plagued me and caused so much confusion as to why so many data store requests were being put into a queue, making me think I was pushing the rate limits too hard, yet it turns out after all this time, there has been a 6 second write cooldown for the same key!!!
This occasionally happened since auto-saves and saving on player leave can happen within that same timeframe, so for servers that have been up for a while, it would have quite a few of them. I’ve implemented custom queues for this since, but I’m sure it’d be even more complex if I had to write to the same key from multiple servers.
21 Likes
Excellent improvement to the DataStore Service. I can see this update fixing a plethora of issues across a great number of experiences, especially ones with trading features. Thank you guys for implementing the change.
16 Likes
This is an amazing change and is honestly very overdue. Very excited to see more possibilities with DataStore now and in the future.
16 Likes
Glad to see it being removed, very convenient for my current project. Thanks!
17 Likes
Data stores became better than before and that’s very great update in my opinion, but does this now mean that data is prevented from being lost from players?
17 Likes
Good change!
If the data store team is looking for more good changes to make, see
17 Likes
Can we expect to see the same functionality with reading a Data Store key?
Currently a read will cache the result and subsequent reads within the limit interval will return the cache instead of making an actual call to the Data Store. Sometimes data need to be altered based on previously existing data. If the read cache cooldown is still at 5 seconds, then it seems like UpdateAsync() may attempt to update stagnant data within the read cache even if a previous write executed successfully.
Other than that, this is a great update.
[EDIT]
I’m fairly confident there is a read cache for UpdateAsync(), but UpdateAsync() performs a read of the most current version of the key. Didn’t even realize the contradiction until now.
[EDIT 2]
It’s not a contradiction, it does one or the other depending if there is an active read cache cooldown.
14 Likes
This is great! Even though I’ve never had issues with data saving as I use both DataStore/OrderedDataStore to save different versions of the player’s data based on the request time (os.time()) so the player can access different versions of their data, or in case there’s an error they can just go back to an old version of their data.
15 Likes