---
title: "Partitions and data distribution"
url: /docs/en-us/cloud-services/memory-stores/per-partition-limits
last_updated: 2026-06-24T18:42:10Z
description: "Explains the concept of a partition and per-partition limits."
---

# Partitions and data distribution

With the release of the `Class.MemoryStoreHashMap` data structure, Roblox removed all existing limits for individual data structures and replaced them with a single, global "per-partition" throttling limit. The exact limit fluctuates based on internal values and how the automatic partitioning process distributes your data, but generally allows for much higher usage before throttling, particularly for hash maps. This new limit enables flexible usage of memory stores across all data structures.

## Partitions

The MemoryStores API stores data on _partitions_, which are just subdivisions of storage. Whenever you write an item to a memory store, that item is stored on exactly one partition. Partitions are fully managed by the MemoryStores API; you do not need to manage them yourself.

## Partition assignment

Partition storage is different according to the data structure an item is being stored on. For sorted maps and queues, each data structure is assigned a single partition.

For example, consider a carnival game with a sorted map called `PlayerScores` and a queue called `PlayerLine` of players waiting to play the game:

Unlike sorted maps and queues, hash maps are allotted multiple partitions, and data is automatically distributed across these partitions. If you were to add a hash map called `Prizes`, the partitions might look like this:

Note how the hash map exists on all partitions, and each partition has some subset of items.

## Limits

Having a per-partition limit allows for higher throughput to all data structures. It also favors hash maps, because they're distributed across all partitions.

For example, consider an example per-partition limit of 50,000 requests per minute (RPM):

- In the very best case, a sorted map and a queue are limited to 50,000 RPM, because each one resides on a single partition.
- Requests to hash maps are spread across the item keys, which are themselves spread across partitions, so hash maps can have a much higher effective limit before throttling, many times that of the other data structures assuming that requests are spread across many item keys.
- Although hash maps can achieve higher overall throughput by spreading requests across partitions, individual item keys are still rate limited to maintain system stability. If most of your traffic targets a single item key, that key may still be throttled.
- To scale effectively and avoid these per-key limits, implement key sharding. Spread reads and writes evenly across multiple item keys to reduce bottlenecks and maintain smooth performance.

For this reason, if you don't need sorting or "first in, first out" functionality, hash maps are usually the best choice for a memory store data structure. For more information, see the [best practices](/docs/en-us/cloud-services/memory-stores/best-practices.md).