Reactor vs Photon Fusion 2 vs Coherence: A Unity Multiplayer Comparison

Reactor, Photon Fusion 2, and Coherence are three of the more commonly evaluated Unity multiplayer solutions for developers who want managed hosting without building backend infrastructure themselves. They have meaningfully different architectures, pricing models, and design philosophies.

Disclosure: KinematicSoup makes Reactor. This comparison is written by the Reactor team. We have done our best to represent all three products accurately using publicly available information, but readers should verify claims independently before making a purchasing decision.

Hosting cost is worth examining carefully before committing to any of these. The sticker price of a multiplayer solution rarely tells the full story. The model used to charge for compute (per CCU vs per CPU-hour), how bandwidth is metered, how efficiently the framework uses that bandwidth, and whether server-authoritative features require additional infrastructure you pay for separately all interact to produce a monthly bill that can be very different from what early estimates suggest. A framework that appears cheap at 50 players may become the dominant cost in your P&L at 500. This comparison covers where each solution stands on the criteria that matter most as a game grows.

Reputation and community

Photon has a long track record. It has been the default recommendation for Unity multiplayer for years, and the community reflects that: extensive documentation, a large pool of developers who have used it, and many public examples to learn from. For developers entering multiplayer for the first time, the ecosystem around Photon lowers the learning curve significantly.

Coherence is newer and has invested heavily in marketing and developer experience to build momentum. The product is polished and the onboarding is smooth, but the community is smaller and the track record shorter.

Reactor has been in development since 2015 and has shipped in commercial games. The community is smaller than Photon’s, and public documentation is less extensive. Developers choosing Reactor are generally doing so for technical reasons rather than ecosystem size.

Developer experience

Coherence has the most polished first-run experience of the three. The tooling is approachable and the product reflects genuine care for how developers encounter it initially.

Photon Fusion 2 is well-documented and the API is straightforward to get started with. The shared mode in particular requires very little setup to have objects syncing across clients.

Reactor takes slightly more to get started. The local development server, server-side scripting model, and separation between client and server code are concepts that require some orientation. The payoff is that synchronization complexity does not grow the same way as features are added. With Photon, managing state synchronization across a growing codebase tends to accumulate complexity. With Reactor, the data model is generated and maintained automatically.

Server authority

All three solutions support server-authoritative multiplayer, but the implementations differ substantially.

Photon Fusion 2 offers two modes. Shared mode assigns authority over objects to different clients: each client owns and drives its own objects, and Photon relays state to others. This is fast to build but not truly server-authoritative. For real server authority, Photon requires the developer to run a dedicated headless Unity server build, manage hosting and orchestration for it, and pay those infrastructure costs separately on top of Photon’s per-CCU fees.

Coherence works similarly. Shared mode assigns object authority to clients. For server authority, a headless Unity instance runs alongside Coherence and handles authoritative logic. Coherence manages some of the synchronization, but the authority layer is something the developer constructs.

Reactor’s room is itself the authoritative server. It runs PhysX physics simulation server-side, handles raycasts, sweeps, and overlap queries, and can be configured with complete authority over all entity state. Client updates are treated as inputs to be validated, not state to be trusted. Reactor also supports a shared authority model where the server assigns ownership of entities to Unity clients or headless instances, providing flexibility for games that do not need full server-side physics. The distinction from Photon and Coherence is that Reactor’s server authority is built in rather than constructed from a headless Unity process running alongside a sync layer.

Bandwidth efficiency

Reactor publishes its bandwidth numbers. In a head-to-head comparison against Photon Fusion 2, Netcode for GameObjects, FishNet, Mirror, PurrNet, and SFS2X, Reactor used approximately 15 kB/s per client syncing 250 physics objects at 30 Hz. Photon Fusion 2 used approximately 112 kB/s under the same conditions. The full methodology, scene configuration, and source are available on GitHub.

Photon has a bandwidth story. It applies compression and delta updates, and the numbers are meaningfully lower than Coherence.

Coherence does not publish bandwidth benchmarks. For games where bandwidth cost matters at scale, the absence of published numbers is itself informative.

Reactor’s bandwidth efficiency comes from data models generated automatically from game state. The developer does not write serialization code. Real deployments have achieved under 1 byte per transform update in games with 100 players and 150 physics objects at 30 Hz.

Hosting costs

The three solutions use different models to charge for compute, and understanding what you are actually buying in each case matters.

Photon Fusion 2 charges per CCU for its cloud relay service (pricing). A CCU in Photon’s model is a player slot connected to the relay infrastructure: it covers message passing between clients but not server-side computation, since Photon’s relay does not execute game logic. Plans are structured as CCU tiers (500 CCU, 1,000 CCU, 2,000 CCU), and each tier includes 3 GB of bandwidth per CCU per month. At Photon’s overage rate of $0.05 per GB in standard regions, that bundled bandwidth represents $0.15 of included value per CCU. In premium regions (Asia, Middle East, South America) at $0.10 per GB, it represents $0.30. Unused fees are credited back automatically, so you are not simply losing unspent CCU capacity. Monthly plans include burst capacity with a 48-hour window to upgrade before throttling. The annual 100 CCU plan does not include burst. For server authority, the developer runs their own dedicated Unity server build on their own infrastructure, paying those hosting costs separately and on top of Photon’s CCU fees.

Coherence charges via a credit system that covers relay and compute (pricing). Unlike Photon, which charges only for CCU relay slots, or Reactor, which charges only for CPU time, Coherence charges for both: CCU connections to the relay and CPU time consumed by simulators, in addition to bandwidth. CCU time is billed at $0.01 per 10 hours, which works out to $0.72 per CCU per month for a player connected around the clock. Bandwidth is priced at 200 credits per GB, with credits costing $0.99 to $1.60 per 1000, working out to $0.20 to $0.32 per GB. The credit abstraction bundles these costs together, which makes it harder to reason about what a given player count will cost per month before you are already paying it.

Reactor Cloud charges for CPU time: rooms are billed by the minute based on the compute size you choose, from $0.02 per hour for a 0.25 vcore room to $0.50 per hour for a 4 vcore room. There is no per-CCU cost as there is for Coherence or Photon. You are paying for actual server-side computation running your game logic and physics simulation, not for player slots connected to a relay. Every paid Reactor tier includes a usage credit equal to the monthly subscription cost, so the fixed fee effectively covers the first equivalent amount of room and bandwidth usage each month. Bandwidth is $0.05 per GB in North America and Europe, $0.10 per GB elsewhere.

For small games, developers can use Reactor’s sync groups and Unity ownership components to divide a connected playerbase into isolated subsets within a single room, effectively creating virtual sub-rooms. Each sync group controls which state is visible to which clients, and ownership components handle data replication between them. The smallest room size supports 100 or more CCU, so a single room instance can carry multiple concurrent game sessions during early growth before scale justifies dedicated rooms per match.

The bandwidth rate gap between Reactor and Coherence is 4 to 6 times. For simple games with few dynamic objects, that rate difference is the main factor. For action games with hundreds of dynamic objects, bandwidth usage scales with entity count, and without an efficiency story Coherence has no mechanism to contain that growth. The rate gap and the volume gap compound: the total bandwidth bill on Coherence for an entity-heavy game can be an order of magnitude higher than the same game on Reactor.

Photon and Reactor are comparable on bandwidth rate, but Reactor’s 7x better efficiency at the same object count and tick rate means the actual egress volume is substantially lower. The 3 GB per CCU inclusion softens Photon’s bandwidth bill for games with low average playtime, but at 112 kB/s per client it covers roughly 7.5 hours of play per CCU per month before overage. For any game with regular engagement, the inclusion covers only a fraction of actual usage. And for Photon in server authority mode, the dedicated server infrastructure costs are separate from and in addition to the CCU fees.

Prices verified May 2026. Pricing pages: Reactor, Photon Fusion 2, Coherence.

Room customization and game types

Photon Fusion 2 and Coherence are well-suited to a defined range of game types: action games, social games, casual multiplayer. Both become harder to work with as the game’s requirements move toward physics simulation, large entity counts, or demanding server-side logic.

Coherence’s simulators are described in vague terms. It is not clear from their documentation what compute resources a simulator represents, whether processing is shared or dedicated, or how to capacity plan against it. Coherence also caps simulator frame rates at 30 Hz, which limits physics simulation fidelity and rules the platform out for competitive games where tick rate directly affects hit registration and input responsiveness.

Reactor rooms are a full processing timeslice: dedicated, predictable compute with defined CPU and memory allocations. The developer knows exactly what the room is running on and can tune accordingly. Reactor supports tick rates up to 120 Hz, giving developers control over the tradeoff between server load and latency. A card game runs at a low tick rate to minimize cost; a competitive shooter runs at a high tick rate for tight input responsiveness. The same room infrastructure handles both.

Reactor rooms are open to the developer in other respects as well. The server supports physics simulation, scene queries, scripted game logic, and room-to-room communication via the Cluster API. There is no ceiling imposed by the framework on what the server can do.

One capability worth calling out separately: in Photon, a player occupies one room at a time. In Reactor, a player can be connected to any number of rooms simultaneously. This enables server topologies that are not practical with a single-room model. A large world can be sharded across multiple zone instances, with players seamlessly connected to the zones around them. Zones can be replicated to distribute concurrent players across instances for load balancing. Separate rooms can run dedicated microservices (global chat, matchmaking, leaderboards, guild systems) that any connected client can interact with independently of their game room. These are architectural patterns that require the multi-room connection model to work cleanly.

At a glance

Which to use

Photon Fusion 2 is the right starting point if community size, documentation quality, and ecosystem familiarity are your top priorities. For simple to moderately complex games where server authority is not critical, the shared mode is quick to build on. The cost structure becomes complicated if you need true server authority, since you are then paying for both Photon and your own dedicated server infrastructure.

Coherence suits developers for whom developer experience and speed to a working prototype are the primary concern, and whose game type does not require bandwidth efficiency or deep physics simulation. The bandwidth cost structure is the sharpest tradeoff.

Reactor is the choice when technical requirements are the binding constraint: server-authoritative physics, large crowds, high entity counts, competitive games, or persistent online worlds. The initial ramp is slightly steeper than the alternatives. The payoff is lower synchronization complexity as the project grows, better bandwidth economics at scale, and a server that can handle game types the other two cannot.

Reactor is free to develop locally and free to self-host up to 32 CCU. Get started here.