Keep persistence on the server. For concurrent writes, use a pure UpdateAsync transform; after a write error, reconcile the backend state before retrying or compensating.
Official sources:
\nFor temporary queues, lobbies, and caches, use MemoryStoreService. Read types-of-datastores.md when choosing a store.
\nCross-reference:
\nIs the data temporary/ephemeral, high-churn, or only needed while servers are active (queues, lobbies, rate counters, short caches)?
\n→ Use MemoryStoreService (queues, sorted maps, etc.). DataStores are overkill and more expensive/slower. See references and official comparison.
Do you need sorted numeric queries for leaderboards or rankings?
\n→ Use OrderedDataStore (via GetOrderedDataStore). Values must be integers. No versioning/metadata. Special GetSortedAsync + DataStorePages iteration. Limits differ (see references/limits...).
Do you need versioning for recovery/audit, user-defined metadata, key listing, or the richer DataStore API (ListKeysAsync, ListVersionsAsync, GetVersionAsync, GetVersionAtTimeAsync)?\n→ Use the full DataStore created via GetDataStore with DataStoreOptions (this returns the modern DataStore class). Preferred for serious player data.
Simple key-value persistent storage without the above needs?
\n→ Use DataStoreService:GetDataStore() (returns a standard DataStore) or DataStoreService:GetGlobalDataStore() (legacy global store, scope \"u\"). For new work, prefer a named GetDataStore store.
Scopes vs prefixes (modern recommendation): For new work, prefer key prefixes (e.g. \"profiles/User_1234\") + ListKeysAsync filtering over legacy scopes. Scopes prepend to keys automatically. Use DataStoreOptions.AllScopes=true + empty scope string for cross-scope listing (see references).
\nStudio access: If Studio needs backend APIs, use a dedicated test experience. Do not enable Studio sessions to read or write production data.
\nSee references/best-practices-and-gotchas.md for full examples and variations (including session locking and profile patterns).
\nHigh-level server flow (in a ModuleScript required by ServerScriptService scripts):
\nOn PlayerAdded:
\nplayerData[player.UserId] = data).During play:
\nOn PlayerRemoving / BindToClose / character death:
\nOn errors during write:
\nUse UpdateAsync with a pure (non-yielding) transform function for any value that can be concurrently modified by multiple servers. It reads-then-writes atomically from the perspective of the last writer.
\nSerialization rules (critical): Only nil, booleans, numbers (no inf/-inf/nan), strings (valid UTF-8), buffer, and tables of the above. No functions, no metatables on saved tables, no cycles. Use HttpService:JSONEncode on suspect data during development to preview what will actually be stored. See references/core-operations... .
\nPopulate on relevant value changes or on save (use SetAsync or Increment).
\nQuery with GetSortedAsync(ascending, pageSize, min?, max?) → DataStorePages. Iterate pages with GetCurrentPage() + AdvanceToNextPageAsync().
\nFor bulk reads, use BatchGetAsync(keys) to fetch multiple ordered entries in one request. Each key counts as one OrderedRead (see error-codes-and-limits for quotas; missing keys are omitted).\nRemember: only numbers; keys are strings; page iteration has its own limits; no versioning.
Display in a ScrollingFrame or via UI on demand. Cache top-N in a standard DataStore if you want fast global access without repeated queries.
\nSee references for full page iteration example and limits differences.
\nEvery Set/Update/Increment on a standard DataStore (not Ordered) creates hourly-versioned backups: the first write to a key in a given UTC hour creates a new version snapshot, and subsequent writes in the same hour overwrite that hourly version. Versioned backups expire ~30 days after being superseded; the current version never expires.
\nRemoveVersionAsync is deprecated. Do not present it as a current cleanup API; retain versions for recovery and use ListVersionsAsync, GetVersionAsync, or GetVersionAtTimeAsync to inspect them.Also use the daily Snapshot Data Stores Open Cloud API before risky publishes.
\nThe Data Stores Manager in Creator Hub lets you browse keys, view metadata/version history, compare versions, and revert (with proper permissions).
\nSee references/versioning-metadata-recovery.md for complete code samples including the \"revert to time of incident\" pattern.
\nBy default: GetAsync results are cached locally for 4 seconds. Subsequent Gets within the window return cache and do not count against limits. Writes update the cache immediately.
\nFor verification after writes (especially after errors), or when you suspect staleness due to other servers:
\nlocal opts = Instance.new(\"DataStoreGetOptions\")\nopts.UseCache = false\nlocal value, info = store:GetAsync(key, opts)\nThis always hits the backend and counts against quotas. Use sparingly but correctly.
\nSee references/versioning-metadata-recovery.md (for listing, caching, serialization) and references/best-practices-and-gotchas.md .
\nThere are experience-level limits (scale with concurrent users across the whole experience) and per-server limits (configurable via DataStoreService:SetRateLimitForRequestType). Experience-level pools are shared between game servers and Open Cloud v2 Data Store traffic. Bulk external jobs can throttle live players (and vice versa).
\nUpdateAsync counts against both read and write budgets.
\nUse DataStoreService:GetRequestBudgetForRequestType(Enum.DataStoreRequestType.XXX) to check before heavy operations and wait in a loop if necessary.
\nQueues exist (size 30); when full, you get throttle errors (301-306 range or the newer *Throttled errors).
\nFull tables of every error code (101 KeyNameEmpty ... through all the *ExperienceThrottled and *GameServerThrottled variants), experience formulas (base 300 + concurrentUsers × N), and server-side errors are in references/limits-quotas-throttling-error-codes.md .
\nObservability dashboard (Creator Hub → Monitoring → Data Stores) shows real-time request counts by API/status, quota usage percentages, storage bytes vs limit.
\nData Stores Manager shows total size vs storage limit (500 MB + 1 MB × lifetime users, measured as compressed latest-version size), per-DS key counts, etc. Do not pre-compress values before writing.
Call SetRateLimitForRequestType early in server init (once per type) to raise limits for migration scripts or busy servers. Base + (perPlayer * numPlayers). Constraints per type are documented.
\nEvery datastore call must be inside pcall.
\nOn failure:
\nGetAsync using UseCache = false.IncrementAsync.committed, rejected, or unknown status so purchase/recovery code cannot mistake ambiguity for failure.Never assume a failed Set/Update/Increment means \"no change occurred.\" UpdateAsync transforms can run multiple times and must not yield or produce external side effects.
RemoveAsync creates a \"tombstone\" (Get returns nil) but older versions remain queryable for 30 days (unless explicitly removed).
\nUpdateAsync from the Engine API or UpdateDataStoreEntry from Open Cloud.See references/versioning-metadata-recovery.md (covers listing/caching) and the manager/observability pages (linked in best-practices-and-gotchas.md).
\nBefore any critical write:
\nOn player join/load:
\nBefore publishing risky data-logic changes:
\nOngoing:
\nThe scripts/ directory contains maturity-labeled examples:
SafeDataStore.lua: reviewed example with automatic read retries, explicit write states, opt-in idempotent replay, and uncached reconciliation.BudgetMonitor.lua: experimental budget-inspection example.Adapt and validate them in a dedicated test experience; this directory is not a versioned production library.
\nCombine this guidance with static analysis, focused tests, Studio integration, observability, and current official sources before trusting a persistence system.
\nFor the authoritative class/property reference for any specific method, always cross-check https://create.roblox.com/docs/reference/engine (search for DataStoreService, GlobalDataStore, etc.).
\n\n