DataStores Migration Packages for the Berezaa Method and DataStore2 Module [Public Beta]

Updates Announcements
#1

Hello Creators,

As mentioned in a previous announcement, DataStores will be enforcing a total storage limit in early 2026. We know managing large data sets in Data Stores is challenging, and we are working through a roadmap of solutions to assist you with your migration and deletion needs.

As one of the steps in this roadmap, we are working on tooling related to the “Berezaa Method” and Kampfkarren’s DataStore2 Module. Today we are launching a Beta of two packages, designed to perform “online” (in-experience players’ data) migration of data stored using the “Berezaa Method” to a Standard Data Store.

The first is a substitution of the DataStore2 module, and the other is a module script with functions for migrating custom “Berezaa Method” solutions.

For specific usages of these modules, please refer to the package links! Adding the modules to your experience will stop the buildup of permanent versions, helping reduce storage growth over time.

While we have conducted our own testing of the modules, we strongly recommend manually testing before a full production deployment to your experiences.

Lastly, a tool for “offline” migration and deletion to clean up the remaining data is coming soon – stay tuned for that! In the meantime, please feel free to comment below with your questions or concerns regarding these packages.

The Roblox Creator Services Team

FAQ

What is the “Berezaa Method”?

The “Berezaa Method” is a mechanism for storing every version of player data indefinitely. It does this by using 1 Standard Data Store and 1 Ordered Data Store per-key per-player.

In the early days of Data Stores, the “Berezaa Method” was useful for providing backups and improving data storage durability. This solved many creator pain points, until Data Stores v2 was released with built-in versioning and improved reliability. Now, it may be an obstacle in meeting the upcoming storage limits, because it leaves numerous backup copies of data in permanent storage, which will never be accessed again.

How do I know if my experience uses the “Berezaa Method”?

The “Berezaa Method” is easily recognizable because of the Data Stores it generates. You can use the recently announced Data Stores Manager to look for two indicators in your experience:

  1. The number of Data Stores exceeds the number of lifetime players for your experience.
  2. Data Stores contain player IDs / other unique identifiers in the Data Store name.

How do the migration modules work?

Both modules work by moving the latest version of a player’s key to a single entry in a Standard Data Store. When reading data, it will first check for the existence of migrated data in the migrated data store, and then fall back to reading the data from the “Berezaa Method Data Store”. See the diagram below as a visual aid.

1600×622 222 KB

By using the migration modules, your experience will stop accumulating permanent versions, slowing your total storage growth.

98 Likes
#2

This topic was automatically opened after 10 minutes.

#3

Will tooling be added to easily delete entire Datastore and groups of keys to reduce storage consumption?

39 Likes
#4

This is great, thanks.

Next, please allow the ability to delete datastores easily through datastore manager or entirely delete datastores effectively.

39 Likes
#5

I’m glad that we’re being given a way to comply with new limits, but I do wonder what implications this will have for data durability and backups. I wonder if we’re going to have a way to reliably keep backups and do versioning without clogging up our datastores now…

Also, do you guys have any plans to add better data management tools? Clearing datastores is a slow chore right now. For this limit update to be acceptable we NEED better tools for cleaning up our datastores and removing old and unused data/datastores. Preferably, there’d be a way to mass-delete datastore keys and there’d be a way to delete entire datastores (with proper security measures in place ofc).

7 Likes
#6

this is awesome thanksss roblocks

2 Likes
#7

“Berezaa method” lmao. Probably responsible for millions of GBs of redundant data. We need a better way to delete datastores.

31 Likes
#8

How do I know the number of lifetime players on my experience?

3 Likes
#9

Thank you all for your comments so far!

And yes, we are working on a tool for effective mass data store deletion. It is a major step on our roadmap and we will make sure to deliver it to you well before the limits go into effect!

37 Likes
#10

Thank you so much. Once this comes out I (along with many others, I’m sure) will feel a lot more at peace with the new limits.

I have one very, very important question though: does this include completely deleting entire datastores? As in removing them from the game? I used to follow not-so-great datastore practices and now I have to mass-nuke roughly 100 datastores from my game. Because I have so many datastores, I cannot view my data usage analytics on creator hub. I really want to clean up my mess so that I can use the analytics page, but there’s no way to remove old datastores. A way to do this, even one-by-one, would be good.

3 Likes
#12

Yes I would like to know this too, I’ve made some mistakes in the past while using DataStores in some of my games and instead of creating new keys, I created new entire DataStores, hopefully with this I’d be able to delete them?

4 Likes
#13

Thats great. For my personal situation, Id like to be able to clear any datastore that begins with a certain string, like “permaworldV2…”

3 Likes
#14

Coooool,
Also will Roblox staff introduce the auto remove data from DataStores for GDPR and CCPA requests?(ssry if this not related to the topic)
Like i know that a devs can use prefixs and the game can have a lot of randomly named DataStores, and due this Roblox don’t know where the player data saved, but why not introduce on CreatorHub settings for game for devs can set it like what they use prefix of keys and the names of DataStores where player’s data saved, so Roblox can use the info for auto-remove the data.

10 Likes
#15

I have been using the berezaa method for a long time now and after the datastore enforcement came out I was kinda worried, however I am still far from reaching the limits.

I have a question regarding it:

  1. I currently use the berezaa method to help with moderation, aka being able to restore the player’s data from any given timestamp. I am far from reaching the limits, does the regular improved datastore roblox offers have a feature like this?
3 Likes
#16

There’s not currently an explicit way to tell (although this would be a useful feature, so let me take note of that for my team).

The best ways to estimate are:

  1. Data Stores Manager future storage quota
    The future storage quota is based on the formula 100 MB + 1 MB * (Lifetime Players). You can use the quota listed on Data Stores Manager and use it to calculate your lifetime players…

  2. If you have any “Welcome” badges that are awarded to anyone who joins your experience, you can use the number of times it’s been awarded to estimate lifetime players.

If you’re unsure of if your experience uses the “Berezaa Method”, I recommend the 2nd option – it’s usually pretty evident by just scrolling through a few pages worth of your data store names. Hope this is helpful!

10 Likes
#17

Thanks for the question! I don’t personally have the answer to this question :sweat_smile: , but let me ask my team and get back to you!

4 Likes
#18

Thank you for the comment - I’ll make sure to bring it up with my team as a feature request :grin:

3 Likes
#19

Does ProfileService/ProfileStore have this same problem?

4 Likes
#20

Whoops, almost missed on giving a useless reply on this one.

3 Likes
#21

Roblox updated datastores to have a built in version system some time in the past. These versions are temporary. You can see the datastore documentation for GetVersionAsync(), GetVersionAtTimeAsync(), …

3 Likes