DataStores without wiping players

Last updated: 15 September 2026 (Asia/Manila)

Most “my players got wiped” reports are not mysterious Roblox bugs. They are SetAsync over a stale table, a missing BindToClose on Studio stop or server shutdown, or a failed pcall you ignored while the session kept running on empty defaults.

Research note: LegitGameplay has not hands-on tested these DataStore snippets in Studio. This guide is Research-based from official Roblox Creator docs and public library pages (retrieved 15 September 2026). Output screenshots are pending. Do not treat the Luau below as hands-on verified on this site yet.

If you missed hour one, start with the Roblox Studio first-hour guide.

What a DataStore actually is

A DataStore is persistent key/value storage on Roblox’s backend, scoped per experience. You reach it only from a server Script (or a ModuleScript required by one) via DataStoreService. It is not a LocalScript feature. It is not leaderstats. Leaderstats are in-memory display values; a DataStore is what survives after the player leaves.

Official overview: Data stores (Creator Hub).

The wipe patterns (and why they hurt)

• SetAsync(full table) after GetAsync without merging. Docs say SetAsync can cause inconsistency when two servers write the same key; last write wins. If your in-memory table was empty because load failed, you just published blanks over real progress.
• Saving only on PlayerRemoving. Studio Stop and live shutdowns race that event. Official BindToClose samples exist specifically so remaining session data still flushes before the server dies.
• Same key, new schema, no defaults/migration. You rename a field, load nil, apply incomplete defaults, then save. Old keys vanish forever.
• Testing wipe logic on a live place with real players. Studio with “Enable Studio Access to API Services” talks to the same production stores unless you use a separate test experience. Roblox warns about this in the data stores guide.

The safer default: UpdateAsync

Official default for player data: Roblox’s data stores guide treats UpdateAsync as the collision-safe way to change existing keys when more than one server might write. Prefer it for profiles. Use SetAsync only when you accept last-write-wins.

Official Set vs Update guidance:

• SetAsync — fast write; can collide across servers; counts as write budget only.
• UpdateAsync — reads the latest key first, runs your transform, then writes; slower; counts as both read and write budget.

If the transform returns nil, the write is cancelled. Creator Hub is explicit: a nil return aborts the update. That is not a successful save. pcall can still return success because the API call itself did not error — your code must treat a nil result as cancel/failure, warn, and not clear the session as saved.

Never return nil unless you intend to skip the update. Merge defaults. Bump a schemaVersion field so future migrations are intentional.

Wrap every call in pcall. On failure, retry with backoff. A failed write does not always mean “nothing happened on the backend,” but you must not keep playing as if the save succeeded — warn, queue another try, and do not overwrite with empty session data.

Minimal researched example (ServerScriptService)

Short original snippet using official API names. Keep session data in a table; load once; save with UpdateAsync; flush on leave and on close. The session-lock check is a simple researched pattern, not a copy of ProfileStore.

If that lock aborts the write (UpdateAsync returns nil), this session’s progress may not persist. That is the tradeoff: you avoid wiping the other server’s newer data; you do not get a guarantee that your coins landed.

local Players = game:GetService("Players")
local DataStoreService = game:GetService("DataStoreService")
local RunService = game:GetService("RunService")

local store = DataStoreService:GetDataStore("PlayerProfiles_v1")
local session = {} -- [userId] = data table
local SCHEMA = 1

local DEFAULTS = {
	schemaVersion = SCHEMA,
	coins = 0,
	sessionLock = nil,
}

local function withDefaults(data)
	local out = {}
	for k, v in pairs(DEFAULTS) do
		out[k] = v
	end
	if typeof(data) == "table" then
		for k, v in pairs(data) do
			out[k] = v
		end
	end
	out.schemaVersion = math.max(out.schemaVersion or 1, SCHEMA)
	return out
end

local function keyFor(userId)
	return "u_" .. tostring(userId)
end

-- pcall success is not a save. UpdateAsync returning nil cancelled the write.
local function retry(fn, attempts)
	attempts = attempts or 3
	local delaySec = 1
	for i = 1, attempts do
		local ok, a, b = pcall(fn)
		if ok then
			return true, a, b
		end
		warn("[DataStore] attempt", i, "failed:", a)
		task.wait(delaySec)
		delaySec *= 2
	end
	return false, nil
end

local function loadPlayer(player)
	local userId = player.UserId
	local ok, data = retry(function()
		return store:GetAsync(keyFor(userId))
	end)
	if not ok then
		warn("Load failed for", player.Name, "- using defaults; do NOT save until load works")
		session[userId] = withDefaults(nil)
		session[userId]._loadFailed = true
		return
	end
	session[userId] = withDefaults(data)
end

local function savePlayer(player)
	local userId = player.UserId
	local data = session[userId]
	if not data or data._loadFailed then
		warn("Skipping save for", player.Name, "- load never succeeded")
		return false
	end
	local snapshot = table.clone(data)
	snapshot._loadFailed = nil
	-- simple session token: refuse overwrite if another server holds a newer lock
	snapshot.sessionLock = { jobId = game.JobId, at = os.time() }

	local ok, newValue = retry(function()
		return store:UpdateAsync(keyFor(userId), function(old)
			old = withDefaults(old)
			if old.sessionLock
				and old.sessionLock.jobId
				and old.sessionLock.jobId ~= game.JobId
				and typeof(old.sessionLock.at) == "number"
				and (os.time() - old.sessionLock.at) < 60
			then
				-- another live session wrote recently; do not wipe with stale data
				return nil -- Creator Hub: nil cancels the write
			end
			for k, v in pairs(snapshot) do
				old[k] = v
			end
			return old -- never nil unless intentional cancel
		end)
	end)

	if not ok then
		warn("Save FAILED for", player.Name)
		return false
	end
	if newValue == nil then
		-- pcall succeeded; the write did not. Do not treat this as saved.
		warn("Save cancelled for", player.Name, "- session lock or abort. This session's progress may not persist.")
		return false
	end
	return true
end

Players.PlayerAdded:Connect(loadPlayer)
Players.PlayerRemoving:Connect(function(player)
	savePlayer(player)
	session[player.UserId] = nil -- memory cleanup after leave; not a "saved" flag
end)

game:BindToClose(function()
	if RunService:IsStudio() then
		-- Docs sample often skips Studio to avoid writing test data into production
		-- and to avoid stalling Stop. Prefer a dummy test place when you do enable API access.
		return
	end
	local left = 0
	for _, player in ipairs(Players:GetPlayers()) do
		left += 1
		task.spawn(function()
			savePlayer(player)
			left -= 1
		end)
	end
	while left > 0 do
		task.wait()
	end
end)

Notes from docs, not our Studio run: UpdateAsync transform must not yield; returning nil cancels the write; a cancelled update is not a successful save even if pcall is true; key names max 50 characters; value max ~4MB serialized; budgets throttle when you spam saves.

Studio checklist

1. Publish a dummy test experience (not your live place with real players).
2. Studio toggle: File → Experience Settings → Security → turn on Enable Studio Access to API Services only on that dummy test place. Leave it off on live experiences with real players — Studio talks to the same stores as production for that place.
3. Open View → Output. Failed saves without Output look like “nothing happened.”
4. Play with a dummy account. Force a Stop after a save. Confirm load on next Play.
5. If a bad write landed: use version APIs. Standard DataStores support ListVersionsAsync, GetVersionAsync, and GetVersionAtTimeAsync for recovery. Ordered stores do not support versioning/metadata the same way.

The BindToClose early-return in Studio is intentional. Do not treat Studio Stop as proof that live shutdown saves work. Use the dummy place.

What not to do

• Do not store a full player profile in an OrderedDataStore. Ordered stores are for sortable numbers (leaderboards). Profiles belong in a standard DataStore.
• Do not save every frame or on every coin pickup. Autosave intervals in Roblox’s own tutorial land around 30–120 seconds, plus leave/shutdown.
• Do not trust the client with the save table. Never let a RemoteEvent hand you “here is my inventory” and SetAsync it blindly.
• Do not ignore failed pcalls and then keep mutating empty defaults.
• Do not treat UpdateAsync returning nil as a good save.

Community patterns (researched, not tested by us)

ProfileStore is covered here as a researched community pattern, not as something LegitGameplay hands-on tested for this draft. Many production games use session-locking wrappers so two servers cannot edit one profile at once. Names you will see:

• ProfileStore (successor; docs at madstudioroblox.github.io/ProfileStore) — researched community pattern only; not tested by LegitGameplay for this draft.
• ProfileService — older sibling; repo itself points new projects to ProfileStore.
• DataStore2 — caching/wrapper pattern with its own docs.

We are not crowning a “best” module here. Read their docs, test on a dummy place, and keep the same rules: no stale SetAsync, no ignored failures, no live wipe tests.

FAQ

Why did my coins reset after a Studio Stop?

Often API access was off (error 403 style), or only PlayerRemoving ran and lost the race. Enable API services on a test place and add BindToClose for live servers.

Is UpdateAsync always required?

For player profiles that multiple servers might touch (teleports, soft shutdowns, trading), yes — it is the documented collision-safe default. Simple single-value counters sometimes use IncrementAsync.

What are the hard size limits?

Per official limits: key/name/scope ≤ 50 characters; value ≤ 4,194,304 characters serialized. Throttling queues hold about 30 requests before drops (301–306 range).

Can I recover after a bad save?

On standard DataStores, list versions or call GetVersionAtTimeAsync, then write a known-good version back carefully. OrderedDataStores lack that versioning path.

Should I test wipe/reset scripts on production?

No. Use a separate universe/place. Studio with API access hits the same stores as the live experience for that place.

Where do leaderstats fit?

Display only. Persist with a DataStore; push values into leaderstats after a successful load.

Did LegitGameplay run this in Studio?

No. This guide is Research-based. We have not hands-on tested these snippets in Studio for this draft. Output screenshots are pending.

Sources

All URLs below were fetched for this draft on 2026-09-15. Pages did not expose a clear “last updated” stamp in the retrieved HTML; treat retrieval date as the citation date.

• Data stores overview — retrieved 2026-09-15
• Error codes and limits — retrieved 2026-09-15
• Save player data tutorial — retrieved 2026-09-15
• DataStoreService — retrieved 2026-09-15
• DataStore (versioning APIs) — retrieved 2026-09-15
• GlobalDataStore (Get/Set/Update/Remove) — retrieved 2026-09-15
• DataModel:BindToClose — retrieved 2026-09-15
• ProfileStore (GitHub) — retrieved 2026-09-15
• ProfileService (GitHub) — retrieved 2026-09-15
• DataStore2 docs — retrieved 2026-09-15

Next on this site can still be a small combat loop. Stuck on a specific Studio DataStore error string from Output? Send it via Contact and we will write from that, not from a keyword list.