Data store error codes and limits

Requests you make to data stores can fail due to poor connectivity or other issues. To handle errors and return messages with an error code, wrap data store functions in pcall().

A failed write call, such as UpdateAsync(), means the game server did not receive a successful response. It does not always guarantee that the backend write did not occur. In some failure scenarios, the final write state may be unknown to the caller until it is verified with a follow-up read without cache.

Error code reference

Server error codes

Limits

Data models have limits. If an experience exceeds these limits, the service automatically throttles the experience's data store usage and causes future requests to be placed in one of the following queues:

• Set
• Ordered set
• Get
• Ordered get

Requests in a queue are handled in the order they are received. The called function continues to yield as long as its request is still queued. If the data store key itself is throttled, the request is placed in a queue but is temporarily skipped.

Each queue has a limit of 30 requests. When the limit of a queue is reached, requests fail with an error code in the 301-306 range, indicating that the requests have been dropped entirely.

Access limits

Data stores are subject to both experience and server-level limits. Experience-level limits scale with total concurrent users across the experience, while server-level limits are configurable and meant to be used as a tool by the creator.

Experience Limits

Each experience is allowed a certain number of data store requests based on the data store type, request type, and number of concurrent users. For each data store type and request type, the limit is shared among all listed functions.

Note that UpdateAsync() consumes from both the read and write request budgets. A single call will decrement both limits.

Standard data stores

Ordered data stores

Server limits

Each server has a configurable rate limit for each request type, based on the number of players in that server. Servers receive a one-time startup burst of additional request budget when they are first created. Use GetRequestBudgetForRequestType() to confirm the number of data store requests that the current server can make at any given time.

These limits are configurable by the creator using the SetRateLimitForRequestType() API. Using this API, a creator can configure their own data stores rate limits for each request type.

The following default rate limits apply if the API is not called:

Standard data stores

Ordered data stores

Data limits

Data stores limit how much data can be used per entry.

The data store name, key name, and scope must all be under a certain character length. Use string.len() to check their length.

The data (key value) is also stored as a string, regardless of its initial type. You can check the size of the data with the JSONEncode() function, which converts Luau data into a serialized JSON table.

Metadata limits

Limits to the number of characters in user-defined metadata.

Throughput limits

Per-key throughput limits ensure that performance is optimal on Roblox servers. Each limit applies to every single key across all servers in an experience and refreshes over time.

Roblox examines the usage of quota associated with the key over the last 60 seconds. If the usage, including the current request, is within the throughput limit, the request is approved. If the usage exceeds the limit, the request is denied.

In addition to the above throughput limits, Roblox organizes data into partitions based on an internal schema. As a result, when the backend server receives a high volume of requests to the same data store, it can result in further throttling. Regardless of the cause, throttling manifests as either DatastoreThrottled or KeyThrottled errors, depending on whether the throughput limit was exceeded for a single data store or a key. These error messages apply to both ordered and standard data stores.

Storage limits

In the future, to provide a scalable and stable storage experience, data stores will implement an experience-level storage limit on your storage usage.

This limit will be the sum of a base limit for each of your experiences and a per-user limit based on the number of lifetime users in your experience. A lifetime user is any user who has joined your experience at least once.

The storage limit will be calculated using the formula Total latest version storage limit = 100 MB + 1 MB * lifetime user count.

Any keys that you delete or replace, even if still accessible through version APIs, do not count towards your experience's storage usage. However, entire data stores deleted via the Open Cloud DeleteDataStore method continue to count towards your storage usage for the duration of their 30-day processing period, until they are permanently deleted.