Data Stores vs Memory Stores | Documentação

To store data, you can use data stores with the DataStoreService or memory stores with the MemoryStoreService.

Alternatively, you can also use Lua types and variables to store data in-memory in Lua, without using the data or memory store services.

When to Use Data Stores

The DataStoreService stores long-term data that needs to last between sessions, such as user progress or inventory items. Data stores are consistent per experience, so every server for every place within an experience can access and change the same data. There are two types of data stores: standard and ordered.

Standard data stores can store data like numbers, strings, and tables that don't need to be ranked or sorted. This data is stored as key-value pairs, where each entry is stored under a key that is unique within its data store and that you can retrieve, update, or delete.

Ordered data stores can only store numbers. Each entry is stored under a key that is unique within its data store and that you can retrieve, update, or delete. You can rank and sort this data numerically and retrieve it in ascending or descending order based on stored numerical values. For more information, see Ordered Data Stores.

	Standard data stores	Ordered data stores
Data type	Numbers, strings, booleans, and tables.	Only numbers.
Common use cases	User progress, inventory items, and experience settings.	All-time, persistent ranking systems and leaderboards. Unlike leaderboards in memory stores, this leaderboard data is permanent.
Past version backup	Automatically manages previous versions of your data for 30 days.	Does not manage previous versions of your data.

Data stores can only be accessed by server-side scripts.

If you want to add granular permission control to your data stores and access them outside of Studio or Roblox servers, you can use Open Cloud APIs for data stores.

When to Use Memory Stores

The MemoryStoreService is a high throughput and low latency service that stores temporary data that needs to be updated or accessed frequently, such as global leaderboards or matchmaking queues. With memory stores, every server for every place within an experience can access and change the same data quickly and frequently. Data in a memory store expires after a certain period of time, lasting up to 45 days.

Although memory stores store temporary data, they also support permanent features like a global marketplace. The marketplace is permanent, but the items for sale inside it have an expiration date.

	Memory stores
Data type	Numbers, strings, booleans, and tables that don't need to persist for over 45 days.
Common use cases	Skill-based matchmaking, match states for multiplayer games, daily and monthly leaderboards.

When to Use In-Memory Storage in Lua

You can use in-memory storage in Lua to store temporary data that needs to be accessed with minimal latency and without the cost of making external service calls to data stores or memory stores. There are no extra steps required to set up in-memory storage as it's already built in by default in Lua.

	In-memory storage in Lua
Data type	Numbers, strings, booleans, and tables.
Common use cases	Data that is only relevant to a single server session and that you can update instantly without worrying about persistence.	Example: Active buffs, temporary points, and ongoing quest progress that resets when the user leaves the experience.
	Values that change frequently, like counters, timers, or state flags.	Example: A user's health bar that updates on each hit.
	Avoiding rate limit restrictions for high-frequency operations in large active experiences.	Example: An experience with dozens of users interacting with the same object.
	Data that drives game logic, like temporary variables or power-up states where quick access with no delay is essential.	Example: A user's current attack state or an enemy's current health, which needs to be accessible instantly and without the latency involved in calling external services like data or memory stores.
	Multiplayer interactions that only matter within a single server.	Example: A shared objective in a co-op mission experience.