Today we are extending our Memory Stores API with a new function for both MemoryStoreSortedMap and MemoryStoreQueue - GetSize()! This function will return the number of items in your data structure. For details on use, see the Creator Hub Documentation.
You may have noticed that this launch does not include the Hash Map data structure. Since Hash Maps are automatically sharded across partitions, getting the total size would require scanning every partition. So, each request would cost as many request units as there are partitions. We are considering a function that allows you to get an approximated Hash Map size based on a sample of partitions, which would lower the request unit usage.
So, we wanted to ask all of you! What use cases do you have for a Hash Map GetSize() function? Would an approximated size meet your needs? Would you rather have an accurate size despite the request cost?
And as always, please leave any feedback on these new functions, make feature requests, and as you always have done, continue to help make Roblox a better platform!
this is actually amazing, it can help us debug things like how efficient we store memories, debugging (potentially) and maybe even help us find memory leak (potentially ofcourse)
Going for both methods could suit general needs, but an accurate size that can be called often and can be reliably read would be preferable. I created an AB Testing system using MemoryStoreService that relies on reading the key count to prevent the over-registration of users. My current method of fetching the number of keys in MemoryStore comes from using another MemoryStoreSortedMap that increments as keys are added. This is more of a “do what we can” solution, so a :GetSize function that can be called frequently would be ideal.
Right now for one of my projects I’m hosting redis database just to use this feature, so it would be very great to see this implemented.
I have a example where I have player “messages” that I need to be able to get across all server in certain amount, so I guess this feature could work to get random messages.
I can’t think of why in certain situations I would prefer to use the approximate version of the function rather than the accurate version. But I do think it would be beneficial to consider adding an Enum parameter or something similar so the developer can choose for their use case.
Could we see this method being added to datastores too? Currently, it’s quite tedious to get all items inside of an OrderedDataStore as we have to go through all of its pages which often requires multiple yielding API calls.
This is amazing! I wholeheartedly support this update as it allows further debugging and allows us devs to get a more in-depth look at memory stores. Thanks Roblox!
isn’t a memory store similar to a data store? like let’s say you somehow handled data the wrong way and each second there is more and more data created
That would be lovely, but it would be killer move if :GetSize() also count as Request into MemoryStore
It is already limiting at 100 * [number of concurrent users] request units per minute.
That is not how it works…? That’s my first time even hearing that.
It’s is just datastore but extremely tiny-sized and it have storage-life-time (ie it will be removed by itself after a certain time)
To add on to the “data handling could result in memory leaks”:
Let us say there is a cache (in a memorystore) used to store references to other locations in a separate memorystore, which if said location doesn’t exist, it is created and populated. Thus, if the data itself is mishandled, it will constantly create new items. Mishandling could be due to a different version of the format without temporary support in place to handle the older format. GetSize() could be used to identify that there is an issue if the size of the memorystore that stores the data is greater in size than the other memorystore.
There isn’t a specific way in which memorystores / datastores works to prevent the situation described.
As was mentioned in other replies, both approaches would be ideal, but if only one can be chosen, the more accurate the better. A usage case for the accurate has already been provided, so I’ll advocate for the approximate.
The approximation has its use too, since the cost for getting the size could be too much for the accurate approach if it needs to be used to validate every attempt at creating an entry, assuming entries are created relatively frequently. The validation is to ensure that the memorystore is not past a certain amount of entries, each player gets their own memorystore. The entries could allow cross server trading, where the recipient gets a trade request, but we want to limit the amount of requests received to 10 per minute. Sent can be limited by the server.
For the math, under some reasonable assumptions (approx = 2 requests, acc = 2+numPartition requests, n = 3 [sample value], countEntries = 10 per player per minute):
Approx: 2 * countEntries + countEntries = 30 requests per player per minute (leaves 70 rpppm for other memstore stuff associated w/ the player)
Acc: (2+numPartition) * countEntries + countEntries = 60 requests per player per minute (leaves 40 rpppm)
So in cases where frequent use is required, the approximation would be very useful but not required. If necessary one could store the size in an item and change it as needed if it reduces the cost. Would be at least as expensive as approx, moreso if synchronization is a potential issue or deletion is required, but less than accurate.
Well there’s no more Roblox University or an actual dedicated group for higher levels of programming/quality projects in Roblox anymore, but you should do that now for DataStoreService as well, instead of just concerning at data size on MemoryStore.
Roblox’s new limits on DataStore also require you as Game-Developer to be careful on your DataStore usages too in 2026, minimalizing data storage and centralising data keys/make it easy-tracking should be something you should look into doing too now.
^ Although they said most games or only top few (30?) are affect by the change, but this is something you should be careful at if you weren’t careful on your datastore sizes and usages per player.
