Roblox Cross-Experience Progression: Data That Follows Players
How to share progression across Roblox experiences: DataStore scope, Open Cloud limits, server-side HttpService, identity, and authoritative writes.
Creators often use the phrase cross-game data when the real question is more specific: is the player moving between places in one experience, or between different experiences? Roblox's official docs make the first case much easier than the second, and that difference is exactly where an external backend starts to matter.
Inside One Experience
Roblox documents that data stores are consistent per experience, which means any place in that experience can access the same persistent data. If your progression only needs to move between places in one experience, the native stack is already strong.
Across Different Experiences
Roblox supports teleporting to another experience when cross-experience teleports are enabled, but that is not the same as giving yourself a universal identity and progression system. Once the player state needs to span separate experiences or external systems, an external backend becomes much easier to reason about.
Important security point from Roblox docs: teleport data is fine for basic non-secure payloads, but not for secure data like currency or inventory. For secure state, Roblox points developers back to data stores or memory stores.
A Practical Boundary
| Scenario | Best Fit |
|---|---|
| One experience, many places | DataStoreService plus secure server-side teleport handling. |
| Temporary data during place hops | Teleport data for non-secure payloads, or memory stores for fast shared state. |
| Progression across separate experiences or external surfaces | External backend with a real identity and persistence model. |
What an External Backend Adds
- A player identity that is not limited to one experience's storage model.
- Shared progression and economy rules across multiple products or surfaces.
- Support tools and audits outside live servers.
- Cleaner migration path if Roblox is only one runtime in a broader platform.
Official Roblox References
Related in This Hub
- Roblox DataStore vs External Database
- Cross-Progression and Cross-Save Backend Design
- Game Server Backend hub
- Roblox Cross-Experience Identity Patterns
If you need progression that survives beyond a single Roblox experience boundary, see Crux.
Frequently asked questions
How does Roblox handle cross-experience player progression?
Roblox does not provide a built-in cross-experience progression service. Native DataStoreService is scoped per universe (experience), so a second experience cannot read the first one's keys. The standard pattern is to call an external backend over HttpService from server scripts in each experience, keyed by the player UserId. Open Cloud lets servers in one experience reach DataStore APIs of another, but it is rate-limited and not designed as a shared progression spine for a large title.
What is the difference between MemoryStoreService and DataStoreService?
DataStoreService is durable, disk-backed key-value storage scoped to one experience, intended for player profiles, inventories, and leaderboards that must survive restarts. MemoryStoreService is in-memory, TTL-bound, and built for short-lived coordination across servers in the same experience: matchmaking queues, party invites, rate-limit counters, and ephemeral session state. MemoryStore offers higher throughput and lower latency but data evaporates on expiry or eviction, so it is never the right home for canonical player progression.
Can I share inventory across multiple Roblox experiences?
Yes, but not with native DataStores alone. The reliable 2026 pattern is to keep the canonical inventory in an external backend (Nakama, PlayFab, or a custom service) and have each experience read and write through HttpService on the game server, never the client. Open Cloud DataStore cross-reads are an option for small studios, but they share quota with the source experience and break down once you add a third experience. The external backend owns the authoritative inventory.
How do I migrate cross-experience data when launching a new game?
Treat the launch as a one-time backfill: export the source experience profiles via Open Cloud DataStore listing endpoints, transform into the new schema, and bulk-load into the destination backend before opening the new experience. From day one the new experience reads and writes through the shared backend, while the old experience either redirects to the new identity or runs in dual-write mode for a deprecation window. Always preserve a Roblox UserId column so cross-link debugging stays straightforward.
What's the rate limit on cross-experience DataStore calls?
Open Cloud DataStore endpoints share the standard Roblox per-experience quota: roughly 60 + 10 per concurrent server requests per minute for GetAsync and similar for SetAsync, with burst caps that throttle aggressively. Cross-experience traffic counts against the source universe quota, not a separate bucket, so a busy second experience can starve the original. For shared progression at scale, route through your own backend such as Crux at https://crux.supercraft.host/ instead of leaning on cross-universe DataStore reads.