13 min read

Source: Roblox Creator Hub · CC BY 4.0 · View source · Code samples: MIT Imported 2026-10-03. Formatting adapted for this site.

Memory stores

MemoryStoreService is a high throughput and low latency data service that provides fast in-memory data storage accessible from all servers in a live session. Memory Stores are suitable for frequent and ephemeral data that change rapidly and don't need to be durable, because they are faster to access and vanish when reaching the maximum lifetime. For data that needs to persist across sessions, use data stores.

Data structures

Instead of directly accessing raw data, memory stores have three primitive data structures shared across servers for quick processing: sorted map, queue, and hash map. Each data structure is a good fit for certain use cases:

• Skill-based matchmaking - Save user information, such as skill level, in a shared queue among servers, and use lobby servers to run matchmaking periodically.
• Cross-server trading and auctioning - Enable universal trading between different servers, where users can bid on items with real-time changing prices, with a sorted map of key-value pairs.
• Global leaderboards - Store and update user rankings on a shared leaderboard inside a sorted map.
• Shared inventories - Save inventory items and statistics in a shared hash map, where users can utilize inventory items concurrently with one another.
• Cache for Persistent Data - Sync and copy your persistent data in a data store to a memory store hash map that can act as a cache and improve your game's performance.

graph TD
    A[Does your data need to be sorted in a specific order?]
    B[Use a sorted map.]
    C[Do you need the ability to scan all of your items at once?]
    D[Use a hash map.]
    E[Do you expect to have fewer than 1,000 keys?]

    A -- YES --> B
    A -- NO --> C

    C -- YES --> E
    C -- NO --> D

    E -- YES --> B
    E -- NO --> D

In general, if you need to access data based on a specific key, use a hash map. If you need that data to be ordered, use a sorted map. If you need to process your data in a specific order, use a queue.

Limits and quotas

To maintain the scalability and system performance, memory stores have data usage quotas for the memory size, API requests, and the data structure size.

Memory stores have an eviction policy based on expiration time, also known as time to live (TTL). Items are evicted after they expire, and memory quota is freed up for new entries. When you hit the memory limit, all subsequent write requests fail until items expire or you manually delete them.

Memory size quota

The memory quota limits the total amount of memory that a game can consume. It's not a fixed value; instead, it changes over time depending on the number of users in the game according to the formula 64 KB + 1.2 KB * [number of users]. The quota applies on the game level instead of the server level.

When users join the game, the additional memory quota is available immediately. When users leave the game, the quota doesn't reduce immediately. There's a traceback period of eight days before the quota reevaluates to a lower value.

After your game hits the memory size quota, any API requests that increase the memory size always fail. Requests that decrease or don't change the memory size still succeed.

With the observability dashboard, you can view the memory size quota of your game in real time using the Memory Usage chart.

API request limits

A request unit quota applies to all MemoryStoreService API calls. This quota is 1000 + 120 * [number of concurrent users] request units per minute.

Most API calls only consume one request unit, with a few exceptions:

• MemoryStoreSortedMap:GetRangeAsync()

  Consumes units based on the number of returned items. For example, if this method returns 10 items, the call counts as 10 request units. If it returns an empty response, it counts as one request unit.

• MemoryStoreQueue:ReadAsync()

  Consumes units based on the number of returned items, just like MemoryStoreSortedMap:GetRangeAsync(), but consumes an additional unit every two seconds while reading. Specify the maximum read time with the waitTimeout parameter.

• MemoryStoreHashMap:UpdateAsync()

  Consumes a minimum of two units.

• MemoryStoreHashMap:ListItemsAsync()

  Consumes [number of partitions scanned] + [items returned] units.

The requests quota is also applied on the game level instead of the server level. This provides flexibility to allocate the requests among servers as long as the total request rate does not exceed the quota. If you exceed the quota, you receive an error response when the service throttles your requests.

With the observability feature available, you can view the request unit quota of your game in real time.

Data structure size limits

For a single sorted map or queue, the following size and item count limits apply:

• Maximum number of items: 1,000,000
• Maximum total size (including keys for sorted map): 100 MB

Per-partition limits

In addition to the game-level request unit quota, memory stores apply request limits to each partition as a safeguard that protects the stability of the service for all games. These limits aren't a quota that your game is allocated, and they aren't a hard ceiling on the throughput your game can achieve. The following values are estimates. They are configured on the Roblox backend and can change, so don't design against them as fixed numbers.

Every request counts toward the limit of the partition that holds the item, whatever the data structure. You can currently expect throttling to begin at roughly 30,000 request units per minute for a single partition, so aim to stay well below that rate. How much of that limit a data structure consumes depends on how its items are distributed:

• Sorted maps and queues each reside on a single partition, so every request to one of these data structures counts toward the same partition limit.
• Hash maps spread their items across many partitions, so traffic spread across many item keys rarely approaches the limit of any one partition.

Hash maps have an additional limit on each item key of approximately 5,000 write request units per minute and 15,000 read request units per minute. This per-key limit applies on top of the per-partition limit, so a frequently accessed key can hit either one. The per-key limit applies only to single-key operations: the read limit applies to MemoryStoreHashMap:GetAsync(), the write limit applies to MemoryStoreHashMap:SetAsync() and MemoryStoreHashMap:RemoveAsync(), and MemoryStoreHashMap:UpdateAsync() counts against both the read and write limits. MemoryStoreHashMap:ListItemsAsync() scans partitions rather than a single key, so only the per-partition limit applies to it.

If you don't need sorting or first-in, first-out functionality, a hash map is usually the best choice because it can spread load across partitions.

When requests exceed a partition or per-key limit, the service throttles them and returns a PartitionRequestsOverLimit status code, which you can monitor with the observability dashboard.

If you expect a data structure or an item key to receive a high, sustained request rate, shard it so that the load spreads across more partitions or keys. Spread reads and writes evenly across multiple item keys to stay within per-key limits. You can also reduce the request rate by caching values on the server and rechecking them after an interval, batching requests where possible, and applying exponential backoff when you receive throttling responses.

Note

We strive to be as transparent as possible about rate limits, but additional, undocumented limits might apply, including for DDoS protection and service stability. Always ensure your game handles throttling responses. See Troubleshooting for guidance.

If you hit an undocumented rate limit that blocks your use case (or you would like higher limits), leave feedback explaining your needs in the Developer Forum.

Best practices

To keep your memory usage pattern optimal and avoid hitting the limits, follow these best practices:

• Remove processed items. Consistently cleaning up read items using MemoryStoreQueue:RemoveAsync() method for queues and MemoryStoreSortedMap:RemoveAsync() for sorted maps can free up memory and keep the data structure up-to-date.

• Set the expiration time to the smallest time frame possible when adding data. Though the default expiration time is 45 days for both MemoryStoreQueue:AddAsync() and MemoryStoreSortedMap:SetAsync(), setting the shortest possible time can automatically clean up old data to prevent them from filling up your memory usage quota.

  • Don't store a large amount of data with a long expiration, as it risks exceeding your memory quota and potentially causing issues that can break your entire game.
  • Always either explicitly delete unneeded items or set a short item expiration.
  • Generally, you should use explicit deletion for releasing memory and item expiration as a safety mechanism to prevent unused items from occupying memory for an extended period of time.

• Only keep necessary values in memory.

  For example, for an auction house game, you only need to maintain the highest bid. You can use MemoryStoreSortedMap:UpdateAsync() on one key to keep the highest bid rather than keeping all bids in your data structure.

• Use exponential backoff to help stay below API request limits.

  For example, if you receive a DataUpdateConflict, you might retry after two seconds, then four, eight, etc. rather than constantly sending requests to MemoryStoreService to get the correct response.

• Split giant data structures into multiple smaller ones by sharding.

  It's often easier to manage data in smaller structures rather than storing everything in one large data structure. This approach can also help avoid usage and rate limits. For example, if you have a sorted map that uses prefixes for its keys, consider separating each prefix into its own sorted map. For an especially popular game, you might even separate users into multiple maps based on the last digits of their user IDs.

• Shard frequently accessed keys in hash maps with multiple copies of the key to distribute load.

• Compress stored values.

  For example, consider using the LZW algorithm to reduce the stored value size.

• Enroll in Extended Services.

  You can increase your Storage and Request Limit quotas by onboarding onto Extended Services

Observability

The Observability Dashboard provides insights and analytics for monitoring and troubleshooting your memory store usage. With real-time updating charts on different aspects of your memory usage and API requests, you can track the memory usage pattern of your game, view the current allocated quotas, monitor the API status, and identify potential issues for performance optimization.

The following table lists and describes all status codes of API responses available on the Observability Dashboard's Request Count by Status and Requests by API x Status charts. For more information on how to resolve these errors, see Troubleshooting. For the specific quota or limit that an error relates to, see Limits and Quotas.

The following table lists states codes from client side, which are currently not available on the Observability Dashboard.

Troubleshooting

The following table lists and describes the recommended solution for each response status code:

Test and debug in Studio

The data in MemoryStoreService is isolated between Studio and production, so changing the data in Studio doesn't affect production behavior. This means that your API calls from Studio don't access production data, allowing you to safely test memory stores and new features before going to production.

Studio testing has the same limits and quotas as production. For quotas calculated based on the number of users, the resulting quota can be very small since you are the only user for Studio testing. When testing from Studio, you might also notice slightly higher latency and elevated error rates compared to usage in production due to some additional checks that are performed to verify access and permissions.

For information on how to debug a memory store on live games or when testing in studio, use Developer Console.