Are there any downsides to using "_G." for storing Data on the server?

I've been looking into making my game more efficient, and I found out about making Global tables/functions. From what I can tell, I'll be able to load a player's data in one server script:

_G.Stats = {}

Players.PlayerAdded:connect(function(Player)
	_G.Stats[Player.Name] = DS:GetAsync(Player.UserId) or {hi = true}
end)

and then be able to access that data from another server script:

_G.Stats[Player.Name]["hi"] = false

Are there any downsides to doing this? Right now, player's stats load in one script and other scripts needing these stats retrieve it through bindable functions. Thanks!

_G is bad style.

One of the principle ways to make your code better is to reduce the scope of everything as much as possible -- when fewer things are at hand, everything becomes less complex.

With _G, every object can peek into every other object's state. That's particularly problematic if two different, unrelated scripts accidentally blunder into using the same keys.

Basically, writing maintainable code using _G is not really possible.

ModuleScripts are a great alternative. They let you box up functionality into functions and state, which lets you have a clean interface for sharing between functions.

You could even use them as a drop-in-replacement for _G by just making them

-- Stats modulescript
return {}

You can easily just say

local Stats = require(game.ServerStorage:WaitForChild("Stats"))

....

Stats[Player.Name] = DS:GetAsnc(.....

though again, I recommend building abstractions and interfaces rather than just throwing data into a table.

Really, the ModuleScript can do a lot of work for you to make your life easier. Think about how you'd like to write code, and then make it possible by designing a nice ModuleScript that behaves that way.