Appearance
Concepts ​
PlayerState persists data with ProfileStore, replicates a filtered view to clients with Replica, and separates per-player versus server-wide and temporary versus saved concerns. You do not need a new mental model for ordinary fields: top-level profile keys still behave as replicated, saved player data.
Start here for how visibility works: Data visibility model — one table for normal data, session, SharedSession, and Server / ServerOnlyRoots.
Choose a guide ​
| Topic | When to read |
|---|---|
| Data visibility | Pick the right bucket before you design DefaultData or config. |
| Session data | Per-player state that syncs but never saves (e.g. session.*). |
| Shared session | One table for all clients on this server, not saved. |
| Server-only player data | Saves per player but never goes to the client Replica. |
| Legacy data migration | Import old DataStore rows during profile load (opt-in). |
| Examples | Common patterns and copy-paste flows. |
| Advanced patterns | Deeper integration ideas. |
| Best practices | Conventions and pitfalls. |
After you know what you are building, use the API overview, server and client references, and types. What's new summarizes recent and highlighted capabilities.