Photon Realtime vs Fusion vs Quantum: What Each Solves
Compare Photon Realtime, Fusion and Quantum: rooms/relay primitives, state synchronization, authority models, deterministic simulation and backend gaps.
Pricing intent: current CCU/bandwidth pricing belongs on the dedicated Photon Fusion pricing page. This page is about product boundaries.
Photon is not one multiplayer product. Realtime is the lower-level networking foundation; Fusion is a higher-level state-synchronization framework with multiple authority topologies; Quantum is a separate deterministic simulation product. Choosing among them answers the realtime-session question. It does not automatically answer where your account records, progression, economy or long-lived operational state live.
Photon Realtime vs Fusion vs Quantum
| Product | What it owns | Choose it when |
|---|---|---|
| Photon Realtime | Low-level rooms/lobbies, matchmaking, region selection, message relay and cloud-webhook primitives. | You want Photon connectivity/session primitives and will build more of the gameplay synchronization model yourself. |
| Photon Fusion | Networked objects/state, RPCs, interest management and authority/input models on top of Photon networking. | You want a higher-level realtime state-sync framework and one of Fusion's Shared, Client-Host or Dedicated Server topologies. |
| Photon Quantum | Deterministic simulation with its own input/state model and rollback/prediction architecture. | Your game is designed around deterministic simulation and you want every peer to derive the same simulation from accepted inputs. |
Do not choose from genre labels alone. The real questions are where state authority lives, whether the simulation can be deterministic, whether you will host a headless server, and what trust model the game requires.
Fusion topology is a separate decision from “use Photon”
Fusion currently supports three materially different topologies:
- Shared Authority: clients own/write state for objects they control; there is no single central gameplay authority for all state.
- Client Host: one player's machine runs the centralized authoritative simulation.
- Dedicated Server: a headless process on infrastructure you operate or obtain from a hosting provider runs the centralized authoritative simulation.
Photon's dedicated-server documentation is explicit that the game-session server comes from a hosting provider and that server orchestration remains a deployment concern. Photon Cloud is still part of the Fusion topology, but Photon does not magically supply the headless compute fleet just because you selected Server Mode.
Quantum is deterministic, not “zero lag”
Quantum's key architectural property is determinism: participants can derive the same simulation from the same accepted inputs, with rollback/prediction techniques used to keep gameplay responsive. That is different from a classic dedicated-server simulation, and it is not a claim that network latency disappears.
Determinism also changes the cheat model rather than eliminating cheating altogether. Photon documents optional/custom server-side verification approaches for stronger protection; you still need to decide what input or result is trusted and what persistent systems accept after the match.
What the Photon realtime layer does not automatically replace
| Need | Photon helps with | What still needs an owner |
|---|---|---|
| Player identity | User IDs and Custom Authentication hooks | Your account lifecycle, linked identities, bans/entitlements and durable profile record |
| Cloud save / progression | Room/object state during the realtime lifecycle | Durable player/world documents and migration/conflict policy |
| Economy | Realtime messages/RPCs can request actions | Trusted balances, inventory transactions, purchase/reward authority |
| Leaderboard/results | The match can determine a result | Durable, idempotent result submission and ranking storage |
| Dedicated compute | Fusion supports a Dedicated Server topology | The headless build, hosting capacity, allocation/orchestration and process lifecycle |
| Live configuration | Room/custom properties can carry session data | Environment-aware durable config/version/rollout policy when your game needs it |
A clean Photon + backend boundary
The safest integration is to let each layer own data that matches its lifecycle:
- Before the room: authenticate the player and load only the durable state required to start the session.
- During the room: keep latency-sensitive simulation state in Fusion/Quantum/Realtime rather than round-tripping ordinary frame state through an HTTP backend.
- At trusted boundaries: checkpoint or submit durable facts such as match completion, rewards, rating changes or world saves.
- After the room: the durable backend remains available after the Photon room/process disappears.
If you use Photon Custom Authentication, your backend can participate in the authentication flow, but that integration must be configured deliberately, it is not automatic just because both systems exist.
Common architecture examples
Fusion Shared Authority + persistent backend
Clients use Fusion's distributed authority model for the realtime room. A backend owns accounts, progression and other durable state. This minimizes dedicated-server operations, but client-owned realtime state has a different trust boundary from a neutral authoritative game server.
Fusion Client Host + persistent backend
One player hosts the centralized simulation. The backend still should not blindly accept durable rewards or ranked results merely because the host says they happened; decide which results are trusted and how host departure/recovery works.
Fusion Dedicated Server + persistent backend
A headless game build owns the authoritative simulation on third-party compute. Matchmaking/allocation supplies a server, clients join, and the server uses trusted backend credentials for durable result/progression mutations. Do not call the persistent backend on every simulation tick.
Quantum + persistent backend
Quantum owns deterministic simulation/input processing. The persistent backend owns player identity, progression, commerce and whatever durable result contract the game defines around that simulation.
Where Crux fits beside Photon
Crux can supply persistent/backend services beside Photon: player authentication, documents, economy, leaderboards, live config and, when your topology needs it, server registry metadata. Photon remains responsible for the realtime product/topology you selected.
Crux does not replace Fusion prediction/state synchronization or Quantum's deterministic simulation. Crux Runtime is currently a separate capacity-gated closed alpha for approved Godot workloads, not a general Photon fleet host.
Decision checklist
- Need lower-level rooms/relay primitives? Start with Photon Realtime.
- Need a higher-level synchronized-object/prediction framework? Evaluate Fusion and choose Shared, Client-Host or Dedicated topology explicitly.
- Need deterministic simulation as a core design constraint? Evaluate Quantum.
- Need durable player/economy/operations state? Add a persistent backend regardless of which Photon realtime product you choose.
- Need a dedicated Fusion server? Budget and design the third-party compute/orchestration path separately.
Related Photon guides
Sources
Technical, pricing, and product claims were checked against these primary sources on the verification date above.