"Cloud save" sounds like a solved problem: write the player's data to a server, read it back on another device. The part that actually bites you is everything around that. What happens when the same player saves on two devices and the writes collide? Can a cheater edit their local save and push it up as authoritative? How big can a save get before the storage chokes, and can it hold a screenshot or a binary blob, not just JSON? And when a player invokes their right to be forgotten, can you actually delete every trace? A backend can make the happy path trivial and still get these hard parts wrong, so "best backend for cloud saves and player data" depends entirely on which of these problems your game actually has.
So this is a map, not a ranking. Below are ten backends sorted by which part of the cloud-save and player-data problem each is best at, with the facts laid out so you can match them to your game. This is a capability where several platforms are genuinely excellent and AccelByte, which builds one of them, is strong without being the automatic answer, so you'll see us hand whole segments to others where they earn it.
We cover AccelByte Public Cloud, AccelByte Private Cloud, PlayFab, Unity Gaming Services, Metaplay, Pragma, Heroic Labs (Nakama), Beamable, LootLocker, and Epic Online Services. Public Cloud and Private Cloud are the same platform on data capability; they differ on deployment, pricing, and compliance, so they're separate rows in the pricing tables and a single row in the capability tables. If you want the wider decision framework, the full backend roundup and the five questions that decide a backend choice are the companion pieces; if your data problem is specifically about progression following players across platforms, the cross-platform play comparison covers the identity side that cloud save depends on.
Short version, if you need it fast:
For save conflict resolution and offline sync, PlayFab and Nakama lead with real version-based concurrency control.
For server-authoritative, tamper-resistant player data, AccelByte, PlayFab, Nakama, and Metaplay all make the server the source of truth.
For large or binary saves, PlayFab (arbitrary file size) and AccelByte (binary records) handle it.
For structured, queryable player profiles, PlayFab and Nakama are strongest.
For free cloud save or open-source data ownership, EOS (free) and Nakama (open source).
And for GDPR, data residency, and clean deletion, AccelByte and PlayFab have the compliance depth. The rest of the page explains why.
A note on fairness before the tables. Storage limits, data models, and pricing drift, and several platforms price by quote. Where a vendor publishes real numbers, we've used them; where they don't, we say so rather than guess. Verify anything load-bearing against current docs before you commit.
Read this for the broad strokes: what the data model is, whether writes have real conflict control, whether the server can hold authority against tampering, and whether it takes binary blobs. The segments below carry the reasoning.
| Platform | Data model | Conflict resolution | Server-authoritative writes | Binary / large saves |
|---|---|---|---|---|
| AccelByte Public Cloud | JSON + binary records, keyed to identity | Server authority (no version-based OCC documented) | Yes (Admin Records, server-only) | Yes (binary to ~100MB) |
| AccelByte Private Cloud | JSON + binary records, keyed to identity | Server authority (no version-based OCC documented) | Yes (Admin Records, server-only) | Yes (binary to ~100MB) |
| PlayFab | Entity Objects + Files | Yes (ProfileVersion, atomic multi-object) | Yes (server API) | Yes (Files, arbitrary size) |
| Unity Gaming Services | Cloud Save items (KV) | Basic (last-write) | Partial (Protected items) | Limited |
| Metaplay | Server-authoritative state (shared C#) | Server-authoritative by design | Yes (by design) | Within model |
| Pragma | Accounts + progression + inventory | Server-authoritative | Yes | Not a focus |
| Heroic Labs (Nakama) | Storage engine (collection/key/user) | Yes (version-string conditional writes) | Yes (server runtime) | Via storage / files |
| Beamable | Managed inventory + stats (C#) | Microservice-managed | Yes (microservices) | Via storage |
| LootLocker | Player storage + progressions | Basic | Partial | Player files |
| Epic Online Services | Player Data + Title Storage (files) | Basic (last-write) | Title Storage is dev-managed | Yes (file-based) |
Cloud save and player data usually ride on each platform's base pricing rather than carrying a separate storage line, though a few meter storage or API calls. Several vendors price by quote; those are marked, not guessed.
| Platform | Pricing model | Free tier | Entry paid tier |
|---|---|---|---|
| AccelByte Public Cloud | Usage-based (PCCU) | Free forever, 30 PCCU/day | Free |
| AccelByte Private Cloud | Usage-based (PCCU) + base fee | None, paid from the start | Starts from $1,500/mo + Usage-based (PCCU) |
| PlayFab | Metered, per-service, tiered plans | Free (capped at 1,000 lifetime players) | $99/mo (Standard) |
| Unity Gaming Services | Metered, per-service (storage + calls) | Per-service free tiers | Pay-as-you-go beyond free tiers |
| Metaplay | Flat rate by DAU | Metaplay Free (local development only) | €195/mo (Starter, capped 5 DAU) |
| Pragma | Usage-based (DAU) + tier fee | 30-day trial | Starts at $1,499/mo (Accounts & Social) |
| Heroic Labs (Nakama) | Free self-host, or usage-based managed | Free (self-hosted) | Heroic Cloud quote-only |
| Beamable | Flat rate by tier | 90-day free trial | Starts at $125/mo |
| LootLocker | Free tier, then quote-only | Free (non-commercial only) | Quote-only beyond trial |
| Epic Online Services | Free | Free, unlimited | Not applicable |
The base case, write a player's progress to the cloud and read it back on another device, is supported by essentially every platform here. If your game is single-player or casual and all you need is "my save follows me," this is close to a commodity, and picking a backend on "does it have cloud save" tells you almost nothing.
Nine of the ten platforms offer straightforward cloud save; the differences that matter show up only when the save gets contested, large, or sensitive. So the useful move for this sub-case is to stop comparing on basic save and go straight to the questions that actually separate these platforms: what happens on a write conflict, whether the server can hold authority, how big and what shape the data can be, and whether you can delete it cleanly. Those are the next four segments, and they're where the real decision lives. Basic cloud save is necessary and nearly universal; it's the wrong axis to choose on.
| Platform | Cloud save | Cross-device sync | Setup effort | Notable limit |
|---|---|---|---|---|
| AccelByte | Yes | Yes (keyed to identity) | SDK + record keys | JSON records ~1MB guidance |
| PlayFab | Yes | Yes | SDK + entity objects | 3 objects/entity on free tier |
| Unity Gaming Services | Yes | Yes (Unity identity) | Editor-native | Device-bound unless linked |
| Heroic Labs (Nakama) | Yes | Yes | SDK + collections | Self-managed if self-hosted |
| Epic Online Services | Yes | Yes (Epic ID) | SDK + storage interface | File-based model |
| Metaplay | Yes | Yes (Unity, non-console) | Server state model | Unity-only |
| Beamable | Yes | Yes | SDK + microservices | Unity-native |
| LootLocker | Yes | Yes | Low-code | Indie-scale |
| Pragma | Yes | Yes | Source integration | Enterprise-oriented |
Here's where cloud save gets genuinely hard, and where AccelByte is honestly not the leader. If a player can be online on two devices, or play offline and sync later, two writes will eventually collide, and without a real mechanism to detect and resolve that, someone's progress silently vanishes. The thing that separates platforms is whether they offer true concurrency control (a way to say "only accept this write if it's based on the version I last saw") versus plain last-write-wins.
PlayFab and Heroic Labs' Nakama are the two strongest here, and both do it properly. PlayFab's Entity Objects system supports atomic multi-object updates with a ProfileVersion, so a conflicting write fails cleanly instead of corrupting state, and you update multiple objects in one operation that either fully succeeds or fully rolls back. Nakama's storage engine uses version-string conditional writes: every object write can carry the version the client last read, and the server rejects it if another write landed in between, which is textbook optimistic concurrency you control in server-side code. For offline-heavy or multi-device games, those primitives are exactly what you need. AccelByte is the honest concession here: its Cloud Save leans on server authority (Admin Records that only the server can write) to protect integrity, which is a real and often sufficient answer, but it doesn't document the same client-facing version-based conflict-resolution primitive that PlayFab and Nakama do, so if fine-grained conflict handling is central to your game, those two lead. Unity, EOS, and LootLocker mostly fall back to last-write-wins, which is fine for single-device play and risky for anything else.
| Platform | Optimistic concurrency | Atomic multi-object writes | Offline-sync friendly | Mechanism |
|---|---|---|---|---|
| PlayFab | Yes (ProfileVersion) | Yes | Yes | Version + atomic entity ops |
| Heroic Labs (Nakama) | Yes (version strings) | Yes (MultiUpdate) | Yes | Conditional writes |
| Metaplay | Server-authoritative | Yes | Yes (server reconciles) | Deterministic server state |
| Beamable | Microservice-managed | Via microservice | Partial | Custom in C# |
| AccelByte | Not documented (server authority instead) | Partial write supported | Via server authority | Admin Records, server-only writes |
| Pragma | Server-authoritative | Yes | Partial | Server-side |
| Unity Gaming Services | Basic | Limited | Risky | Last-write-wins |
| Epic Online Services | Basic | No | Risky | Last-write-wins |
| LootLocker | Basic | No | Risky | Last-write-wins |
For any competitive or economy-driven game, the data that matters, currency balances, rank, unlocks, inventory, cannot live where the client can edit it. Server-authoritative player data means the server, not the game client, owns those writes, so a tampered client can't grant itself currency or items. This is a sub-case where several platforms are genuinely strong, including AccelByte, and the honest framing is a four-way lead rather than a single winner.
AccelByte handles this cleanly with Admin Records: sensitive player and game data that only an authorized server can read or write, kept entirely out of client reach, alongside player-accessible records for the data players legitimately own. PlayFab does the same through server-authenticated entity APIs and CloudScript, keeping authoritative writes server-side. Nakama's server runtime (Go, TypeScript, or Lua) runs your authoritative logic in-process, with object-level permissions that can mark data server-write-only. Metaplay is arguably the purest expression of this model: its whole architecture is server-authoritative by design, with shared C# logic where the server is always the source of truth.
The distinction between these four is less about whether they do it and more about how: AccelByte and PlayFab via server-only record types, Nakama via a permissioned runtime you code, Metaplay via an architecture that's authoritative from the ground up. Unity's Protected items offer a lighter version of the same idea; the rest leave more to your own implementation.
| Platform | Server-only data | Mechanism | Client-tamper resistance | Also has client-owned data |
|---|---|---|---|---|
| AccelByte | Yes (Admin Records) | Server-only record type | High | Yes (Player Records) |
| PlayFab | Yes | Server-authenticated entity APIs + CloudScript | High | Yes |
| Heroic Labs (Nakama) | Yes | Permissioned server runtime | High | Yes |
| Metaplay | Yes (by design) | Server-authoritative architecture | Very high (structural) | Via model |
| Pragma | Yes | Server-authoritative | High | Yes |
| Unity Gaming Services | Partial (Protected items) | Server-writable items | Medium | Yes |
| Beamable | Yes | Microservices | Medium-high | Yes |
| LootLocker | Partial | Server flags | Medium | Yes |
| Epic Online Services | Title Storage only | Dev-managed storage | Medium | Yes (Player Data) |
Not every save is a small JSON blob. Games that store screenshots, replays, user-generated content, photo-mode captures, or large serialized world states need a data layer that takes arbitrary binary data at real size, not just stringified JSON with a tight cap. This is a narrower requirement, but if it's yours, it eliminates several platforms fast.
PlayFab is the most flexible here: its Files system stores arbitrary binary data of any size against an entity, separate from the size-limited JSON objects, with a CDN for delivery. AccelByte handles binary well too, with dedicated binary records (images, audio, and arbitrary .bin data) uploaded via pre-signed URLs at up to around 100MB per record, plus partial-write support to avoid re-uploading a whole blob for a small change.
EOS is a genuine option for this specific need, its Player Data Storage is file-based and built for save files, and it's free, though without the structured query or concurrency features of the others. Nakama stores binary through its storage engine, and LootLocker offers player files at indie scale. The platforms to rule out for heavy binary are the ones oriented around structured state: Unity's Cloud Save is built for smaller key-value items, and Metaplay's model is about deterministic game state rather than large blob storage.
For big or binary saves, PlayFab (unlimited file size) and AccelByte (binary records with partial writes) are the most complete, with free EOS a real option if you don't need the extras.
| Platform | Arbitrary binary | Practical size ceiling | Partial / chunked writes | Delivery |
|---|---|---|---|---|
| PlayFab | Yes (Files) | Arbitrary | Atomic file ops | CDN |
| AccelByte | Yes (binary records) | ~100MB per record | Yes (partial write) | Pre-signed URL |
| Epic Online Services | Yes (Player Data Storage) | Generous per-file | Chunked | Epic infrastructure |
| Heroic Labs (Nakama) | Via storage engine | Self-managed | Atomic writes | Self-hosted or Cloud |
| LootLocker | Player files | Indie-scale | Basic | Managed |
| Unity Gaming Services | Limited | Small items | Limited | Managed |
| Beamable | Via storage | Managed | Via microservice | Managed |
| Metaplay | Within model | State-oriented | N/A | Managed |
| Pragma | Not a focus | N/A | N/A | N/A |
Some games treat player data as documents to save and load; others need it as a database, structured profiles you can query, aggregate, and segment on (find everyone above rank X, everyone who owns item Y, everyone who hasn't logged in for a week). If you need to ask questions of your player data rather than just store and retrieve it, the data model matters more than raw storage.
PlayFab and Nakama lead here because both give you a real, queryable data layer. PlayFab's entity model plus PlayStream and segmentation lets you define player segments and query against player state, backed by an analytics pipeline. Nakama stores JSON objects you can query with JSONB (Heroic Labs supports custom query work), plus structured leaderboards, stats, and a wallet ledger, all in a data layer you can inspect directly, especially if self-hosted. AccelByte is solid in this area with its Statistics service for structured stats and queryable records, and it's a capable option, but for deep, flexible querying and segmentation PlayFab and Nakama are the stronger picks. Metaplay and Beamable both hold structured player state well within their models, and Unity's Cloud Save is more document-oriented than queryable.
For player data as a queryable database, PlayFab and Nakama are the two to start with.
| Platform | Structured profiles | Queryable / segmentation | Stats service | Analytics pipeline |
|---|---|---|---|---|
| PlayFab | Yes (entities) | Yes (PlayStream, segments) | Yes | Yes |
| Heroic Labs (Nakama) | Yes (collections) | Yes (JSONB queries) | Yes | Via Satori / self-built |
| AccelByte | Yes (records + Statistics) | Partial (record queries) | Yes (Statistics) | Via analytics add-ons |
| Metaplay | Yes (server state) | Within model | Yes | Yes (LiveOps dashboard) |
| Beamable | Yes | Partial | Yes | Yes |
| Pragma | Yes | Server-side | Yes | Partial |
| Unity Gaming Services | Document-oriented | Limited | Via Analytics | Yes (UGS Analytics) |
| LootLocker | Yes (profiles) | Basic | Yes (leaderboards) | Basic |
| Epic Online Services | Stats + Achievements | Limited | Yes (Stats) | Limited |
Two kinds of team have a hard constraint on this axis: those who want cloud save at zero cost, and those who need to own the data layer outright, whether for data-sovereignty reasons or to avoid depending on a managed vendor for the thing their game's saves live in. This is a segment where AccelByte is plainly not the answer, and it's worth saying: AccelByte is a managed platform, and while its trial is free up to 30 concurrent players, its source is Enterprise-only with no self-hosting path below that.
Epic Online Services is the free answer: Player Data Storage and Title Storage, synced to an Epic identity across platforms, cost nothing and cover the core save-and-sync need for a lot of games, with the tradeoffs being last-write conflict handling, no structured query, and Epic operating the infrastructure. Heroic Labs' Nakama is the data-ownership answer: it's open source under Apache-2 and self-hostable for free, so the entire storage engine, and every byte of player data in it, runs on infrastructure you control, with the option to move to managed Heroic Cloud later. The tradeoff is the usual self-host burden: you run the database, backups, scaling, and on-call. Metaplay is a softer version of data ownership, it ships source you can self-host at any paid tier, so you control the data without the full open-source-from-scratch setup. For genuinely free cloud save, EOS; for owning the data layer outright, Nakama. AccelByte isn't the pick for either, and that's the honest call.
| Platform | Free cloud save | Open source | Self-host player data | Data-ownership model |
|---|---|---|---|---|
| Epic Online Services | Yes (entirely free) | No (free SDK) | No (Epic-operated) | Free, Epic-hosted |
| Heroic Labs (Nakama) | Self-host is free | Yes (Apache-2) | Yes | Full ownership (self-host) |
| Metaplay | Local dev only | Ships source | Yes (any paid tier) | Source, self-hostable |
| AccelByte | Trial to 30 PCCU | Enterprise-only | No | Managed |
| Beamable | 90-day trial | Enterprise license | Own-cloud option | Managed or licensed |
| Unity Gaming Services | Free tier | No | No | Managed |
| PlayFab | Free (capped) | No | No | Managed (Azure) |
| LootLocker | Free (non-commercial) | SDKs only | No | Managed |
| Pragma | Trial | Licensed source fork | Your fork | Source fork |
Storing player data is a legal obligation as much as a technical one. Under GDPR, CCPA, and similar regimes, you have to honor deletion requests completely, and depending on your market you may need data to physically reside in a specific region. This is compliance plumbing that's easy to ignore until an audit or a deletion request makes it urgent, and it's a sub-case where AccelByte is genuinely strong.
AccelByte is built with this in mind: it's GDPR and CCPA compliant out of the box, supports full player-data deletion, and its Private Cloud deployment gives dedicated infrastructure and data isolation for teams with hard residency or compliance requirements, exactly the case where a shared multi-tenant platform won't pass review. PlayFab is an equal peer here, backed by Microsoft's compliance apparatus and Azure's regional data-residency options, which is hard to match for a team that needs formal certifications and specific geographic hosting.
The rest vary: Nakama self-hosted gives you total control over residency and deletion because you run the infrastructure (the compliance is yours to implement, but so is the control), while the managed platforms depend on each vendor's own compliance posture and regional coverage, which you should verify against your specific legal requirements.
For built-in compliance depth with a managed platform, AccelByte and PlayFab are the strongest, with self-hosted Nakama the answer if you need to control residency yourself.
| Platform | GDPR / CCPA compliant | Full data deletion | Data residency options | Deployment isolation |
|---|---|---|---|---|
| AccelByte | Yes (out of the box) | Yes | Yes (Private Cloud) | Yes (dedicated infra) |
| PlayFab | Yes (Microsoft compliance) | Yes | Yes (Azure regions) | Azure tenancy |
| Heroic Labs (Nakama) | Self-implemented | Yes (you control) | Yes (self-host anywhere) | Full (self-host) |
| Metaplay | Yes | Yes | Yes (self-host option) | Yes (self-host) |
| Unity Gaming Services | Yes | Yes | Limited regions | Managed |
| Pragma | Yes | Yes | Your infrastructure | Your deployment |
| Beamable | Yes | Yes | Own-cloud option | Own-cloud |
| Epic Online Services | Yes | Yes | Epic-operated | Managed |
| LootLocker | Yes | Yes | Limited | Managed |
Two widely used platforms deserve a specific placement for cloud save, because both are common starting points that fit some games perfectly and constrain others.
Unity Gaming Services Cloud Save is the natural default for a Unity team: it's in the editor, it's simple, and its Protected items give you a measure of server authority. For a single-player or casual Unity game, it's often all you need. The constraints specific to this capability are that its identity is device-bound unless you do the account-linking work (so "cross-device save" isn't automatic), its conflict handling is basic, and it's more document-oriented than queryable. For a Unity game whose data needs are simple, it's a fine pick; for one with contested writes, heavy binary, or deep query needs, the specialists pull ahead.
Epic Online Services keeps showing up because free, cross-platform Player Data Storage and Title Storage genuinely cover the core save-and-sync need at zero cost. The right way to think about EOS for cloud save is the same EOS-plus-one framing that applies across its whole surface: use its free storage and identity for what they do well, and pair a fuller data layer alongside it when you need conflict resolution, structured queries, or compliance guarantees it doesn't provide. It's a strong free foundation, not a complete player-data platform, and it slots into a lot of stacks on exactly those terms.
| Sub-case | Best fit | |
|---|---|---|
| Basic cross-device save | Nearly everyone | commodity |
| Save conflict resolution | PlayFab / Nakama | leads elsewhere |
| Server-authoritative data | AccelByte / PlayFab / Nakama / Metaplay | AccelByte among leaders |
| Large & binary saves | PlayFab / AccelByte | AccelByte among leaders |
| Structured & queryable data | PlayFab / Nakama | leads elsewhere |
| Free & open-source ownership | EOS / Nakama | leads elsewhere |
| GDPR, residency & deletion | AccelByte / PlayFab | AccelByte among leaders |
It depends on which part of the problem is hard for your game, which is the whole reason this page is a map, and on this capability the honest answer genuinely spreads across several platforms. For save conflict resolution and offline sync, PlayFab and Nakama lead with real concurrency control. For server-authoritative, tamper-resistant data, AccelByte, PlayFab, Nakama, and Metaplay are all strong. For large or binary saves, PlayFab and AccelByte. For structured, queryable player data, PlayFab and Nakama. For free cloud save or open-source ownership, EOS and Nakama. And for GDPR, residency, and clean deletion, AccelByte and PlayFab. AccelByte is a genuine leader on server authority, binary storage, and compliance, and a capable option elsewhere, but this is a category where it isn't the automatic answer, and pretending otherwise wouldn't help you choose.
Figure out which of those problems is actually yours, contested writes, tamper resistance, big blobs, queryable profiles, free or self-hosted, or compliance, and the ten options collapse to two or three worth a serious trial. Pick those, then build your real save-and-load flow on each and test the hard path, two devices writing at once, a tampered client, a deletion request. That's the test that actually answers this.