We are happy to announce that the trace back period for the Memory Store size quota has been extended from 1 day to 8 days to accommodate the cyclic traffic pattern for many of the experiences!
Previously, the size quota was calculated based on the maximum CCU (concurrent users) in the past 24 hours, which gives some buffer time for your experience to expire the data. However, we’ve learned that many experiences have peak traffic during weekends (e.g. Saturdays) and a sharp drop on Mondays. If you store lots of data during the peak time but don’t expire it in time, your quota will be suddenly reached on Monday, potentially breaking the experience. To mitigate the issue, we have extended the trace back period to 8 days (to account for long weekends) so that your quota is less likely to be met.
In the meantime, there is a trade-off we’d like to call out: you could use either a small memory size with a long expiration time, or close to the full size (1KB per user) with a short expiration. It may cause trouble if you store a large amount of data with a long expiration. In general, we recommend setting the shortest expiration time possible based on your needs instead of using the maximum (45 days).
Thanks again for your feedback, which helps us keep improving the service! There are a few more substantial changes for the service coming. Stay tuned!
This is great news for creators who have problems with storage quota sizes. Increasing the lookback window to 8 days provides more flexibility for experiences with cyclical traffic patterns, especially those with weekend peak traffic. The Creator Services team has explicitly considered feedback and made changes to improve the service. The team recommends using the shortest expiration time possible based on your needs, which is also valuable advice. It’s great to see the team continue to make big changes to the service, and we look forward to hearing more about them. Thanks to the Creator Services team for their hard work and dedication to improving the service!
This is great news. Glad to see Roblox watching and taking care ALL there developers. Not just the groups, but some that have problems that others don’t.
Thank you for the update! I’d like to suggest putting this in a big red warning box on the documentation page; since it has the potential to break experiences if used incorrectly, it feels like something to definitely not miss, esp. for younger devs who may try and skim these to quickly get things working.
As I’m new to Roblox game designs… this has me with questions.
What exactly does this store… inventory or something else ?
Assuming a player has a 2 week Roblox break… this would not lose them their inventory items surely ?
I know its probably a stupid question (no such thing lol) … but worth clarifying.
Thanks
Dumbed Down Explanation:
memory stores are essentially low latency, temporary versions of datastores (which are used to store player data). instead of being used to store player data, these can be used to store things like matchmaking data, things that you might want to access on all servers, without storing them to the slower, permanent datastores and instead a temporary, fast working version of them- memorystores
Using SortedMap method of the memory store, can you keep extending the expiration time of the memory store if you keep updating the expiration time? Just curious lol
I’m looking for some clarifications on MemoryStore Limits. According to the documentation Sorted-Maps:
Keys have a size limit of 128 characters, and the value size limit is 32KB.
The memory quota limits the total amount of memory that an experience can consume. It’s not a fixed value. Instead, it changes over time depending on the number of users in the experience according to the following formula: 64KB + 1KB ⨉ [number of users].
Maximum total size, including keys for sorted map: 100MB
So to clarify the relationship between all of these: Any individual key can store 32KB (but if each user has a key, it should be less than 1KB because of universe limits), up until a universe limit of 64KB + 1KB ⨉ [number of users] and this universe limit is a combination of the data in all SortedMaps / Queues in the experience (e.g. sharding won’t help it). Finally, if you have over 100,000 users, then the universe limit is high enough that individual Queues/SortedMaps are limited to 100MBs?
