I’ve heard storing things inside ReplicatedStorage can increase memory usage, could this be avoided by storing them inside ServerStorage instead?
To add more detail to what I’m currently planning on doing this with;
I’m making a game that has multiple maps, and the server has control over what map gets used and removed in the game.
I’m just gonna put this out there, NEVER store objects in ReplicatedStorage unless they are not important game assets.
Always use ServerScriptService and ServerStorage for ANY critical scripts such as economy, datasaving, or any other data based asset which could be targeted by exploiters.
Memory usage would go down, yes, as the ServerStorage is not replicated to the client directly.
Your maps can just be stored in ServerStorage, since the clients don’t have any particular need or use and the map clone will be replicated when it’s parented to the workspace. Generally speaking, anything you’d want the client and server to have access to should be stored in ServerStorage, while all else should be stored in ServerStorage, though you need to maintain security. Yes, storing things in ServerStorage won’t increase the memory usage of the clients, since objects that are descendants of ServerStorage aren’t replicated to the clients
You accidentally said ServerStorage twice 
I assumed as much, but wasn’t sure if there was more pitfalls to storing things inside the server, and then introducing things to the client later, I assumed something as big as a map being instantiated could cause issues on lower end connections or systems.
Thanks for clearing that up for me 
Parden my passing interruption, but with maps being stored in ServerStorage that can one say that there could theoretically be no limit as to how many maps one could have in the game? The reason why I ask is because I’ve heard of some games limiting their maps to a finite level, and now I wonder if in fact all of these maps simply exist client side.
A parallel track in my mind then asks the question why one would link a place with another place if one could bring down a map/level when needed. I think Egg Hunt 2018 used linked places.
Thanks for entertaining my query and have a great day!
Can I please see the evidence / reasoning you have for not using ReplicatedStorage?
@loterman23 If you want the client to be able to access objects, then put them in ReplicatedStorage. If only the server needs to access them, put them in ServerStorage
Location in the server doesn’t affect how much is stored - storing Map1 in workspace will still require the same amount of memory to store in ServerStorage. The only factor is if you need them replicated to each client.
So there’s no concept of “store this ONE map here on client when I need it” remove it from memory when I don’t. Whatever I have in ReplicatedStorage WILL come down to client, Hence this is why people eventually used linked places?
If they are stored in the server storage, not having to replicate them means less parts that the client has to manage which could lead to performance gains. Would that be correct?
Imagine it like this:
You have a hard drive labeled C:\, two folders (Desktop and Documents), and a file (Map.dat)
Would the hard drive have any less or more storage space if you moved Map from Desktop to Documents? The only difference is that in the Desktop it’s displayed to users who log in.
If that analogy makes sense, no there is no concept of storing things out of memory - it doesn’t make sense (they have to be stored somewhere).
Yes, of course. So, don’t replicate them if you don’t need the client to have access to them.
Thanks for the analogy. Let me approach the question from another angle. If I had a game where performance was needed and the number of maps was too much for the client, how would I approach this? Based on your recommendation of using ReplicatedStorage, then the answer would be “limit the number of maps”. Correct? Or could I approach this a different way?
Trying to establish some basic patterns and dos and don’ts. I’m guessing linked places is one way to work around this, but not understanding if that’s the only tool my utility belt.
If you’re loading in maps:
No, we store them in models and load via insertservice. This is the best approach since it keeps the server memory lower. It’s especially important once you get a lot of maps, it adds up pretty quickly
Thank you for your feedback and responses. Your comment about server memory piqued my interest. What impact does server memory have on the game, are there some best practices on game development you can pass based on your experiences in managing it, and what tools are available for us to manage it? All I know is the client F12 but assumed it was client only.
Thanks I won’t veer this conversation in anymore directions. 
What about 25k+ trees? on a GIANT map
Do you want to back that up with some kind of explanation? I use it sparingly, as in, important static instances that the client should have replicated with the initial snapshot (especially shared modules) but I wouldn’t ever think of ReplicatedStorage as “completely useless”.
ReplicatedStorage is almost completely useless
Why do you say that? At least for me, I use it for storing modules and if ever, values that can be read by the client
Ive never thought about using it like that. I’ll delete my uneducated comment
If you store it in ReplicatedStorage or ServerStorage, the only difference is who has to load it. If you need clients to see it, then you should load it into ReplicatedStorage (but if you’re going to do that instead of putting it in Workspace, why store all the trees? Instead generate the trees when the player loads to save server space)