We’re thrilled to announce that MemoryStore - a brand new data service that offers access to in-memory data structures shared across all servers in an experience - is now available to everyone!
In addition to persistently saving data such as player profiles in DataStore, we understand that there are many use cases that need more frequent, ephemeral data access. For example, you may want to build a global marketplace with shared inventories across all servers where the data needs to be updated frequently. Moreover, you may want to have a skill-based matchmaking system so that players can enjoy more engaging competitions. You’ll need fast data access to manage player pools for those who want to be matched.
With high throughput, low latency data access across all servers, the MemoryStore service now makes it easier to implement these features. Instead of raw data access, the service offers data structures such as sorted maps and queues so that you can integrate it faster. To learn more about the service, check out our Tutorial and API reference documentation.
We cannot wait to see what you will build with MemoryStore! As always, your feedback is invaluable for us to keep improving the service. Feel free to post any questions you may have. Our team will monitor the posts regularly and get back to you.
The Roblox Developer Services Team
- MemoryStore is designed for fast but non-persistent data access. The data will be removed when expired. So use DataStore if you need the data to be persistent. The relationship between DataStore and MemoryStore is similar to harddrive and memory in a computer.
To improve performance, you can use MemoryStore as cache for some of the features, e.g. the global marketplace, but the cache should be in-sync with DataStore for persistent storage. In such cases, DataStore should act as the source of truth for your data.
- There is no flush API in the initial release as we feel it may cause more issues than the benefits it brings (we may consider it in future improvement). All of your data has a mandatory expiration after no more than 30 days. We recommend setting the shortest possible expiration time based on your use case so you can rely on it to recover your storage quota.
- The service offers a separate Studio namespace, which is isolated from your production data and automatically used when you are developing in Studio. This means you can safely test in Studio without worrying about impacting your production data.
On the other hand, you will have to use Developer Console to debug your production experiences since the Studio tools will not be available. Check out our Tutorial to learn more.
- There’s no API to get the quota usage info today, and we are considering to add one as future improvement. On the other hand, when you exceed either the size or request quota, your API calls will be throttled and get an error message that contains the details of your quota usage. You can use that info to debug your code.