Depends on the sandbox type, infinite world gen types like Minecraft are difficult because the storage space goes beyond 4 megabytes easily
this would most likely only be in a worst case scenario where the entire chunk is full of something that requires a lot more data like chests. otherwise, it’s very unlikely that a single chunk is gonna surpass that limit.
Could we get tools to help us mass-delete datastores/keys from multiple datastores to get Total Size down?
In the past my game had used different keys for each “version” of player data which since Roblox has provided us with Datastore Versioning has been redundant, in spite of this left over keys that can’t be converted (unless they can be automatically which I’m not aware of with current tools/methods?)
Ideally it would be nice if you guys at Roblox could provide us with tools to wipe all “keys” but the latest based on a specific (as you call them) “scope” within all Datastores? That way safely we can remain to use the current converter for players that haven’t played the game since that converter was integrated and should prevent players from loosing data.
This is the current situation I’m facing as a result of this and haven’t received any DMs about being within that 30 total experiences of the top “55 million” despite my game being told by the analytics it resides around the top 5,000 
2 Likes
This is just a visual bug, it will not be your real limit.
1 Like
my voxel game seems to be doing alright
If you’re compressing your files correctly you should be fine.
Keep in mind if your table vars have long names that gets like multiplied per block.
Come up with a format with helper functions to compress your tables.
Alternatively… don’t use tables to begin with, use buffers to get the most out of the storage space you have with an efficient data structure.
2 Likes
Considering how much space I’ve got with my current system I probably won’t have to worry about it but yea buffers would be better.
My game is planned to be an open world game with a lot of savable data, which is required for player progression and making the city feel alive. My game is not on the map, and this will make it essentially impossible for me, a solo developer with a teeny tiny game, to garner new players who want to experience this game without rapidly running out of storage space. And having such a constrictive limit on my game’s data will make it basically impossible to allow players to have multiple save slots like I’d originally planned. This update is absolutely stupid and has no place on Roblox because it doesn’t “Power Imagination”. It will kill small, ambitious games so quickly and only make the issue of crap; low-effort games worse since quality games keep getting harder to make.
1 Like
Then you should plan ahead and save/load data from an efficient format. You might be surprised to realize how much space you can save on player data with your own data format that is not just JSON tables.
Try building the game first. Plan out your storage format, do some math. You will probably be surprised. You’re not going to ship with multiple save slots as version 1 anyway, and by the time you do, Roblox will probably have released a way for you to pay for more storage space, where if you are even slightly successful, you will be able to afford. Again, 200 CCU and 3 purchasable products are paying for my groceries.
It is a waste of time and energy to panic over hypotheticals when 99.999%+ of experiences (where many of those experiences are already doing what you’re planning to do) are just fine.
1 Like
I do plan to ship with save slots as a version 1 because my game is a story game and progression is entirely dependant on the player’s other progression data. It’s also become a serious issue of Roblox making developers pay for things that other development platforms ship with out of the box; one instance being videoframes. I also shouln’t have to spend a ton of money when most of the money I make from this game won’t be mine anyway. There are always going to be data optimizations that can be made, but players aren’t going to want to keep playing if their data randomly doesn’t save one day because I don’t have enough concurrent players.
1 Like
I’m a solo developer working on a massive project, data is an important part of my entire game, and making it harder to use data in my project is going to kill momentum on my project for something that I’d planned to be an afterthought to be refined after the game’s initial release. It’s stupid that this is just going to be the norm going forward because of an update that just about nobody asked for.
1 Like
you don’t have to keep it in the efficient format when it is loaded into your game, you just need to use that efficient format when you save/load it, it really isn’t as hard as you believe it to be.
I was trying to avoid this, but I might have to rely on CreatePlaceAsync for user-generated worlds in my game. I’d practically have infinite storage this way.
Theoretically, I could just store serialized version history under the place itself instead of into a DataStore. And in the rare case where a place gets too big to save, I can literally just create another place. This could probably work.
Most experiences will be fine, but I know that I’m going to be dealing with an insane amount of data.
It’ll make saving and loading data more complicated on the backend, and could allow for more edge cases that could lead to the not saving/mishandling of player data, tanking recurring player counts, and making it so I have even less data available to work with. Even if it’s not very complicated, it’s a principle matter of making it harder for anyone who really wants to make games with complex environments that use a lot of data not being able to because there game can no longer support the data they needed, or they have (or don’t have) a team too small to properly manage that. It’s kind of smothering and doesn’t adhere to Roblox’s mission statement of powering people’s imagination.
Glad to know my game isn’t on that 100MB baseline 
So many good updates dropped I’m speechless. I thought that the updates that dropped around the time of occlusion culling were good but this might be even crazier!
Buffers are typically very inefficient when stored in a DataStore, they have a 25-30% byte-for-byte overhead. This is because they’re converted to a string when stored, and the format for the string is Base64, not only is this inefficient but Base64 also doesn’t compress very well. (Roblox applies compression to DataStores, the final size of the compressed key is what counts to your data limit, not the raw data size.)
If you can save more than 25-30% of the bytes over standard JSON by using a buffer, then it could be worth it, but for many cases I’m not sure about this, in my experience JSON formatting accounts for like 10% of the data size, and this is with a complicated table structure, experiences with a simpler table structure would benefit less. (that is, if it’s possible for them to benefit at all.)
IMHO - I don’t think it’s worth the effort given that there’s no guarantee that you’ll save much data, if any at all. It’s much better to simply design your initial data structure to be as optimized as possible. If you’re still running out of data, then off-site storage would be the only option at least until Roblox provides more details about what scalability options will be provided to creators.
I’m certain this will only improve as time goes on, however. I can’t imagine they would make this update without any form of plans to make it possible to store data inside of a datastore more efficiently.
2 Likes
Theme Park Tycoon 2 is EXTREMELY good when it comes to storing data, because you can have like hundreds of thousands of objects in your park and it barely takes up 1mb of data. Also, this could ruin Theme Park Tycoon 2.
3 Likes
i know we could but , due to the sheer amount and the rate limits , it would be a lot easier to run if they just add a method for that on their end. and it will Probably take less time.
and we have migrated most if not all the old data from these old Data Stores to a new brand ones.
these are just dead data that are floating around.
1 Like