Managed game backend vs custom: the structural difference
The comparison is usually framed as cost, which is the least decisive part of it. Framed structurally, the difference is a single boundary:
Everything else — SDK quality, dashboard polish, which regions are covered — is real but recoverable. Where the boundary falls is not: it decides which problems you are allowed to solve.
Two builds on this site sit on the right-hand side of that boundary, and both are there for the same reason rather than for scale. Metarun runs server-authoritative 1v1v1 races with anti-cheat and MMR matchmaking — decisions that have to commit inside a tick — and held 39,000 concurrent players at 60 ms average round-trip and 99.8% uptime. The multiplayer backend behind an anonymised mobile title reached 52,000 peak concurrent at 62 ms and 99.98%. Neither crossed the line because it got big. Both crossed it because the rule that decides a result had to run where the state already was.
Photon, Nakama, PlayFab, AccelByte: what each one actually is
| What it is | Examples | What it does not cover |
|---|---|---|
| Real-time networking | Photon Realtime | Accounts, persistence, inventory, economy, leaderboards. It carries the session, not the player |
| Managed game backend (BaaS) | PlayFab, AccelByte, RallyHere, brainCloud, LootLocker | Server logic the platform will not run; schema freedom; predictable cost at scale |
| Open-source backend you host | Nakama | Nothing structurally — but you now own operations, which is the cost people forget to count |
| Custom | Your own services | Nothing, and that is the point. You also own every failure mode |
The middle two rows are where most titles should sit, and the honest position for a company that builds custom backends is to say so. We do say so on discovery calls, because a studio that buys a custom backend it did not need discovers that in month three and remembers it for years.
What a managed game backend costs per concurrent user
The two options do not just cost different amounts — they have different shapes, and the shape is what matters over a title's life.
Managed is a variable cost that tracks success. Photon Realtime, as published in August 2026, is billed per concurrent user in fixed steps: a free 20-CCU development tier, then plans at 100, 500, 1,000 and 2,000 CCU, and above that usage-based pricing at roughly $0.29 per CCU against a monthly minimum, with traffic billed separately per gigabyte. Those specific figures will move — check the current page before planning against them — but the shape will not. Every player you gain increases the bill, and the increase is a step function rather than a smooth curve, so growth arrives as a series of cliffs.
Custom is a fixed cost up front and a variable one underneath. The build is scoped once; the infrastructure then scales roughly linearly with concurrency, and the compute is cheaper per player than a platform charges, because you are buying compute rather than compute plus a product. The catch is that "cheaper" only counts if someone is operating it, and operations is a real line item that does not appear in a build quote.
Both sides, with numbers, at 5,000 concurrent players. Photon Realtime at its published $0.29 per CCU comes to about $1,450 a month for the transport layer, with traffic billed on top. The equivalent self-hosted stack — session tier, edge, event fabric, persistence, observability and egress — comes to about $6,880 a month on AWS list prices, and roughly $4,070 of that is egress alone. The two figures are not substitutes: one is a session transport, the other is a whole backend including everything Photon Realtime explicitly does not carry.
What the split does show is where the "cheaper per player" claim holds and where it does not. Compute, yes. Bandwidth, usually not. A platform buys transit at volumes a single studio cannot, while a studio on a hyperscaler pays $0.09 per gigabyte at the first tier — which is why egress is the largest line in the self-hosted model at every scale above the smallest. So do the crossover arithmetic per line item rather than on a blended rate, and do it at your real update rate: at 2 kB/s per player instead of 12, the same stack's egress falls by four fifths and the answer can change direction.
The crossover is therefore not a CCU number. It is the point where the platform's margin on your traffic exceeds what it costs you to run the equivalent yourself plus the engineering you are no longer buying from them. For a title with modest custom-logic needs that point may never arrive. For one that is fighting the platform from month one, it arrived before launch.
Four questions that decide build or buy
- Does any decision have to be made inside a tick? Server-authoritative validation, anti-cheat, an economy rule evaluated before a result commits. If yes, the loop has to be yours; a callback across a network is not an answer.
- Whose schema is the game's schema? Adopting a platform's data model wholesale is what makes migration impossible later. Keeping your own identity and your own player model costs a little up front and preserves the option.
- What is the realistic peak, and when? Per-CCU pricing at a peak you will not reach for two years is not a reason to build now. Model the bill at the peak you actually expect.
- Who is on call? Custom means your team, at three in the morning, during an event. That is a staffing decision before it is an architecture one — and if the answer is "nobody yet", buy.
How to buy now without locking yourself in
For most titles the correct order is: buy first, own your data model, measure, then decide. Ship on a managed backend, keep player identity and the core schema in your own store rather than the vendor's, instrument the cost per thousand concurrent users, and revisit when either the bill or the custom-logic friction becomes a real number instead of an anxiety.
What makes that revisit cheap is the same discipline that makes any backend maintainable — one writer per piece of state, and a clean boundary between what the platform holds and what you hold. Teams that observe it can migrate one subsystem at a time. Teams that did not are looking at a rewrite, and it usually arrives at the worst possible moment, which is right after the title succeeds.
If you are at that decision now, we will give you the honest read on a call — including, often, that you should stay where you are. What building one costs when it is the right answer is broken down in what a multiplayer backend costs, and what we build is here.