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

Reactor, Photon Fusion 2, and Coherence are three of the options developers evaluate for Unity multiplayer with managed hosting. They differ in architecture, pricing model, and design philosophy.

The short answer: Reactor runs game logic and physics on a built-in authoritative server and bills for compute time ($0.02 to $0.50 per room-hour by size) plus bandwidth at $0.05 to $0.10 per GB. Photon Fusion 2 is a relay billed per CCU, and server authority means running your own dedicated servers on top of the relay fee. Coherence bills CCU time, simulator compute, and bandwidth through a credit system, with bandwidth at $0.20 to $0.32 per GB. In a controlled benchmark syncing 250 physics objects at 30 Hz, Reactor used about 15 kB/s per client and Photon Fusion 2 about 112 kB/s; Coherence does not publish bandwidth numbers.

At a glance

Coherence claims re-verified against their own documentation on 2026-10-02: areas of interest, level of detail, simulator limits, credit and bandwidth pricing, and SDK plans. Reactor and Photon figures are from May 2026. Pricing pages: Reactor, Photon Fusion 2, Coherence.

Disclosure: KinematicSoup makes Reactor. This comparison is written by the Reactor team. It draws on public information from all three vendors. Verify claims against each vendor’s documentation before making a purchasing decision.

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, that ecosystem lowers the learning curve.

Coherence is newer. Its onboarding requires little setup, its community is smaller, and its track record is 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 who choose Reactor tend to do so for technical reasons rather than ecosystem size.

Developer experience

Coherence puts the most work of the three into the first-run experience; setup is short and the tooling is approachable.

Photon Fusion 2 is well documented and the API is straightforward to start with. Shared mode requires little setup to sync objects across clients.

Reactor’s structure differs. It uses a local development server and a server-side scripting model. That structure is familiar to anyone who has done backend or dedicated-server work, and it separates client and server code, defines what is shared between them, and shortens build times by decoupling client builds from server builds. With Photon, state synchronization code grows with the codebase; Reactor generates and maintains the data model from game state.

Server authority

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

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 the server holds no authority over the objects. 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 uses the same pattern. 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 validated before they change state. 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 about 15 kB/s per client syncing 250 physics objects at 30 Hz. Photon Fusion 2 used about 112 kB/s under the same conditions. The full methodology, scene configuration, and source are available on GitHub.

That test runs every engine at its defaults and syncs all 250 objects to every client, with no culling anywhere. Running both levers at once makes it impossible to read what a single update costs.

Coherence doesn’t publish bandwidth benchmarks. Their documentation gives one worked figure: an animated humanoid with position, orientation and animator parameters takes 913 bits per update at full fidelity, and 372 bits at their second level of detail.

All three engines delta-compress against previous state. They diverge on what happens when the changed state doesn’t fit in a packet.

Photon Fusion 2 and Coherence both work to a budget of roughly 1280 bytes. When more has changed than fits, both send the highest-priority updates and hold the rest for a later packet with their priority raised. Coherence describes the result as “a lower sampling rate for those entities rather than one group never being sent”. Photon applies eventual consistency to networked properties and documents what it costs: an integer going 5 to 6 to 7 in quick succession can reach other clients as a single change from 5 to 7, and a boolean going true to false to true can reach them as no change at all.

Reactor compresses the update itself. Data models are generated from game state, so the developer writes no serialization code, and the encoder works against a fixed simulation tick on an authoritative server. Real deployments have achieved under 1 byte per transform update in games with 100 players and 150 physics objects at 30 Hz.

A deferred update arrives late. A coalesced property change never arrives.

This is also what sets the floor on hosting cost, since egress is billed per gigabyte regardless of which engine produced it.

Interest management

Every networking engine solves bandwidth the same way first: stop sending things players cannot see. The three differ in what they ask the developer to do, and in what happens if the developer does nothing.

Coherence calls this Queries, and at least one is mandatory. Their documentation is explicit: “You need at least one query in your scene, or you won’t see anything update over the network.” A Live Query defines a cube around a transform, and anything outside it is not synced. Tag Queries make specific entities visible regardless of distance, and Global Queries cover entities marked global.

Queries combine as a union, so spatial and tag filtering cannot currently be intersected; Coherence lists combined restrictions as a future feature. And when a non-authoritative entity falls outside every query it is destroyed, then re-instantiated when it comes back, which is why their documentation recommends object pooling and a buffer distance to stop entities thrashing at the boundary.

Coherence also has a network level-of-detail system, and it is the most developed of the three. A prefab can define distance thresholds where components stop replicating entirely or individual fields drop to fewer bits, baked into the schema. Their own worked example takes an animated humanoid from 913 bits to 372. The documented limitation is that it reduces what the server sends to clients. What a client sends up is unaffected: “a ‘fat’ object with tons of fields will still tax the network and the Replication Server if it is constantly updated, even if it uses a very optimized Archetype.”

Photon Fusion 2 has area-of-interest culling, and it is off by default. Enabling it means changing Replication Features in the network config from the default to “Scheduling and Interest Management”, then registering regions in code. Their own troubleshooting documentation tells developers that more than 32 players in a fast-paced action game “likely will require you to implement interest management.”

Reactor uses sync groups. The scene divides into spatial cells, players enroll in the groups holding nearby entities, and assignment logic lives in one server room script. All entities start in group zero, which syncs to everyone.

What actually differs

Not the presence of the feature. All three have one, and all three replicate everything until a developer configures otherwise. Coherence’s getting-started guide has you create the mandatory query and leave it unbounded; Reactor’s group zero syncs to everyone; Fusion ships with interest management switched off.

What differs is how hard you have to cull before the bandwidth is acceptable. The engine that moves fewer bytes per update filters less aggressively for the same result, which buys a larger interest volume, more entities visible at once, or a higher send rate, for the same bytes on the wire.

It also changes what interest management is for. When culling is the only lever, the interest volume is set by the bandwidth budget and the game design follows the network. When the per-update cost is low enough, the interest volume can be set by what the game needs players to see.

Coherence’s defaults put a ceiling on this independently of culling. The replication server sends at 20 Hz into a 1280-byte packet by default, which their documentation works out to “around 24KB/s” per connection. Both the packet size and the send rate are adjustable, though tuning them on the dashboard requires a paid plan.

In Coherence a query is owned by the client that holds it, so a tampered client can widen its own view. Making the interest volume tamper-resistant requires server-side-with-client-input setup or handing queries to clients from a Simulator; their documentation covers both. In Coherence, interest management is a bandwidth optimisation. It becomes an anti-cheat boundary only with that setup.

Hosting costs

Four inputs set the monthly bill: how compute is charged (per CCU or per CPU-hour), how bandwidth is metered, how much bandwidth the framework uses, and whether server authority requires separate infrastructure. A framework that is cheap at 50 players can become the dominant cost at 500. The three solutions charge for different things.

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. 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 the monthly cost of a given player count difficult to estimate in advance. Two further costs are easy to miss. CCU hours bill on the capacity a room reserves rather than on players present: “The calculation is based on the maximum player capacity these are reserved for, regardless of how many players are active within them”, so an over-provisioned room is billed as if it were full. And the SDK itself is a subscription above a revenue threshold, free for companies under $200k in revenue or funding and $1,000 per month or $8,000 per year above it (pricing), which is a fixed annual cost before any hosting for a studio that crosses that line.

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 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, 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 charge similar bandwidth rates. At the same object count and tick rate, Reactor’s egress volume is about 7x 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 about 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.

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 documentation does not state what compute resources a simulator provides, 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 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 what the room runs on and can tune for it. 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. The framework does not limit what the server code can run.

In Photon, a player occupies one room at a time. In Reactor, a player can hold connections to any number of rooms at once. 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 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 patterns require the multi-room connection model.

Which to use

Photon Fusion 2 is the right starting point if community size, documentation quality, and ecosystem familiarity are your top priorities. For games of low to moderate complexity 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 physics simulation. The bandwidth cost structure is the main 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 result is lower bandwidth cost at scale and server capabilities the other two provide only with separate infrastructure.

Reactor is free to develop locally, and self-hosting is free for registered game titles up to 32 CCU per room. Cloud hosting starts at $20 a month. See the install steps.