This is great news. Due to one of my current projects, I’d love to see the server limit increased as well. While I am attempting to optimize data storage as much as possible, including using character bytes, dynamically shared data, and caching, it would be exceptionally useful to have that “per user” amount be increased in the future.
6 Likes
Oh my goodness FINALLY! Thank you so much I’ve been waiting so long!!!
7 Likes
Why you need the limit increase ?
7 Likes
Great change. To sum it up, you can now instantly reach the request limit without having to think about a cooldown queue. It would be interesting to know whether this new system gets rid of the queue so it errors if you reach a limit or reaching the limit causes throttling where every request is queued and sent when it can be sent.
4 Likes
The specific project I’m referring to can potentially require a relatively large amount of data requests. It’s hard for me to explain without giving more detail, but the amount of data requests needed is per-player, and therefore very easy to hit the limit. While I still believe I can make things work within the current limitations, having an increased limitation per-player would make a significant difference in worse-case conditions.
The only reason I believe I can do this within the current limitations is because these worse-case scenarios won’t be all that common. But they’ll become more likely over time and with more players in a given server, unless they stick closer together. Even an increase of 1 or 2 requests per-player would be helpful, but I’d prefer anywhere from 5 to 10 (of an increase).
I realize that the vast majority of experiences won’t need this, at least if they’re coded correctly, but there are certain larger scale experiences that would benefit greatly. Even aside from larger scale experiences, there’s also more data oriented experiences that would also benefit from increased data requests.
I would like to emphasize that I’m hoping for an increase in the amount of requests per minute, not the size of the request. MemoryStores won’t work as they’re not meant for long-term data, but current DataStores have a long cooldown. I’d even be fine if there was a specific type of DataStore that had greatly reduced cooldowns in exchange for less data capacity (though still preferably at least 1 to 2 mb if possible). Perhaps there could be API for requesting a datastore of a specific size, where the cooldown limit scales based on the size.
Though regardless of how this would be done, I would certainly love to see an increase in DataStore requests per minute (preferably per-player).
6 Likes
To me the removal of 6s Cool down is really usefull to make a crew/guild system
7 Likes
This is great! No longer will the output be filled to the brim with datastore queue warnings.
9 Likes
Modern experiences seem to have an auto-save feature to mitigate the amount of data loss if Roblox servers go down. Many developers have also chosen to update directly after an important change such as a purchase with Robux. This means the read cache is returned if the auto-save feature updates directly before a player makes a purchase. I think the prompt in-game to make a Robux purchase has a waiting time of less than 6 seconds; if true, then multiple purchases also have a chance to return the read cache.
A threshold could mostly solve this, but it wouldn’t be impervious to a large percentage of players spam-buying; and would definitely fall flat against GetAsync spam. A threshold also wouldn’t hold up against cross-server communication which is originally why my reply included a suggestion to add another Data Store API. I may have over-extended a little to try to get a session-locked Data Store API, but if one is created, then it would cut down on the amount of read requests. We wouldn’t need to use UpdateAsync so much to manually session-lock and most experiences should only ever need one read request per play session. The DataId’s used in session-locking make the read cache a factor.
3 Likes
pretty nice, so this means set requests are done immediately? does it make pre-existing datastores more reliable?
4 Likes
awesome update, I was having some data problems with an older game of mine because the code was outdated, pretty sure this was the exact problem (because of the way I wrote it) this is awesome!
4 Likes
The timing of this change is amazing
4 Likes
They are sharing the same cache internally, so it doesn’t make sense if we only make GetAsync() bypass the cache, while the other APIs don’t.
3 Likes
Set requests (including Set, Increment and Update) to the same key will be executed sequentially, but there is no wait time between two set requests.
5 Likes
Interesting, so I am guessing before this update extra calls would just use cache?
3 Likes
I hate to bother but can you clarify the documentation on :UpdateAsync() wrt my example:
For example, if I call
:UpdateAsync()twice in lock-step will the second:UpdateAsync()return a cached value, i.e. the first value set by:UpdateAsync()?
The documentation only notes that :UpdateAsync() happening at the same time from different servers will rerun the callback on the second :UpdateAsync() but doesn’t provide an explanation on the behaviour of the previous example
3 Likes
Is this change live yet? I am on studio and I got the old cooldown message on a GetAsync call
4 Likes
This specifically targets the 6 second cooldown on SetAsync, IncrementAsync and UpdateAsync. Quota limits are still in-place and enforced.
2 Likes
Datstores got so much better with this! Thank you. 
2 Likes
I would also like to know the answer to this.
2 Likes
We still needs Session locking,the problem still exist.
Imagine Player A leave a server and rejoin really fast before his data could save so he get his previous version of data (before a trade for example)
Video that explain well ProfileService: Getting started + Analyzing item duplication on Roblox - YouTube (only watch beginning)
4 Likes