CC @RuizuKun_Dev, This is adding onto what you were saying in your post.
I wouldn’t recommend _G because ModuleScrips serve as a much, much, much better alternative. _G may seem good to use initially when you have a small code base but when you start using it extensively everywhere you will find yourself getting confused as to what is and isn’t stored in it. This makes reading and updating your code a lot harder. Be very careful when using _G and only use it when you really need to.
_G has so many limitations compared to using ModuleScrips: You can’t store stuff for both client and server to access. You won’t be able to take full advantage of OOP with _G because of how much more confusing it will be. Why would you store all your global stuff in one table?
Why modules are a better alternative:
ModuleScripts have so many more advantages than _G because of how organisation friendly and versatile they are. Modules allow you to split your code, in your case tables, into smaller chucks making reading, updating and maintaining your code a lot easier. Compared to _G modules are a lot more visually friendly as well.
If you want the client and the server to both access the same table, like a configuration module, then this can be done easily by placing a module within ReplicateStorage. Whereas with _G this is non existent because the client and server both have separate _G tables.
Another advantage with using modules is that you can OOP a lot easier than you would be able to with using _G. With the use of modules you can have a separate module for each object(I think this is the right terminology) you create making it visually easier to update. You can also make it so the client and server can both access the module as explained above.