Networking stacks by game size: NGO, Netcode for Entities, Mirror, FishNet, Photon

This page helps pick a stack. Recording the choice, authority and verification is covered by UNITY-NETWORKING-IS-PROJECT-SELECTED on Choosing a netcode stack & Netcode for GameObjects. Unity's own connection services (Relay, Lobby, Matchmaker) are not a netcode framework; they sit under any of these and are covered on Unity Multiplayer Services.

Versions and dates were read on 15 Oct 2026: Unity packages from the Unity package registry, Mirror, FishNet and the backends from their GitHub release pages, Photon from its documentation.

The approaches, before the frameworks

Topology. Client-server: one process owns the game and clients connect to it. The server is either a dedicated server (a headless build you host) or a host (a player's game that is also the server). Distributed or shared authority: each client owns some objects and a cloud service relays state; there is no single game server. Peer-to-peer: clients exchange state directly. Unity's Netcode for GameObjects supports client-server and distributed authority; Netcode for Entities supports client-server only (Unity multiplayer overview, Unity 6.2 manual).
Authority. Whoever holds authority over a value decides it; everyone else proposes. Server authority resists cheating; client or shared authority is cheaper and simpler but trusts players.
Prediction. With server authority, a client that waits for the server feels lag. Client prediction runs the local player's input immediately and corrects when the server's answer arrives; rollback re-simulates from the corrected state. Netcode for Entities ships a client prediction framework; in other stacks, check what the framework provides before planning it.
Reachability: relay versus dedicated. A player-hosted game usually cannot accept incoming connections through home routers, so traffic goes through a relay. A dedicated server has a public address and needs no relay, but you pay to host it and run a fleet.

Comparison

Game sizes here are concurrent players in one session or world: small (2 to 8), medium (tens), large (around a hundred or more), MMO-scale (thousands in one persistent world). Where the vendor publishes no number, the fit is described in words and says so.

Option	Version (date)	Topologies	Good for	Size fit, with source
Netcode for GameObjects (`com.unity.netcode.gameobjects`)	3.1.0 (4 Oct 2026)	Client-server (host or dedicated), distributed authority	MonoBehaviour projects; adding multiplayer to an existing single-player game; co-op and casual	Small to medium. Unity: "a smaller number of players and less complex game logic" (Unity's netcode packages). No official player cap.
Netcode for Entities (`com.unity.netcode`)	7.1.0 (3 Oct 2026)	Client-server only	DOTS projects; competitive action with prediction and lag compensation	Medium to large. Unity: "large numbers of players and complex game logic", recommended "for large-scale games that require heavy optimization" (netcode packages, multiplayer overview). No official player cap.
Mirror	v96.11.3 (17 Sep 2026)	Client-server (host or dedicated); many swappable transports	MonoBehaviour projects that want a mature open-source library with built-in interest management	Small to large. Mirror's docs describe interest management as how to "scale to thousands of connections" (Interest Management); no official player cap.
FishNet	4.7.3 (2 Sep 2026)	Server-authoritative design, host mode; other topologies through transports	Server-authoritative MonoBehaviour games that want built-in prediction tools and no CCU charges	No official size figure. FishNet's docs state "no CCU caps or CCU paywalls" (What is FishNet?); scale depends on your server and hosting.
Photon Fusion 2	Fusion 2 (docs "current")	Dedicated server, client host, shared authority (Photon Cloud room)	Teams that want hosted rooms and matchmaking; shared mode for casual and mobile	Photon recommends client host for "few players within a session (2-4)", shared mode for casual games "or those with a lot of players", dedicated server for competitive games with many users (Choose a topology). Billing caps by CCU: free 20 CCU (development only) and free 100 CCU for one launched app; paid plans of 500, 1,000 and 2,000 CCU (Fusion pricing).
Photon PUN 2	maintenance / LTS	Photon Cloud rooms with a master client	Existing PUN projects only	Photon: "PUN 2 is in maintenance / LTS mode ... New projects should consider Fusion or Quantum" (PUN intro).

Photon CCU tiers are account-wide billing limits on concurrent users across all rooms, not the size of one session.

Pick this when

Netcode for GameObjects: pick it when the game is built with GameObjects, a session holds a few to a few dozen players, and you want Unity's first-party stack with Multiplayer Services integration.
Netcode for Entities: pick it when the game already uses Entities and needs server authority with prediction for fast action or many simulated objects. Do not adopt DOTS only to get this package; see The DOTS stack.
Mirror: pick it when you want an open-source, server-authoritative GameObject library with interest management built in and transport choice. Rules: Mirror networking.
FishNet: pick it when you want a free, server-authoritative GameObject library with prediction tools and you will host your own servers.
Photon Fusion 2: pick it when you want the vendor to host rooms and matchmaking and you accept per-CCU pricing; use shared mode for casual and mobile, server mode when cheating matters.
Photon PUN 2: only when maintaining an existing PUN project.

MMO-scale: what none of these gives you out of the box

None of the options above is documented by its vendor as a complete MMO solution. Each provides replication for one server process or one room. A persistent world with thousands of players additionally needs:

Interest management so each client only receives what is near or relevant to it. Mirror ships it (Interest Management); Netcode for Entities documents ghost and snapshot optimisation (Optimize performance).
Sharding or zoning: splitting the world across many server processes, with hand-off of players between them. No framework above documents this as a built-in feature; you design it.
A dedicated server fleet with allocation, scaling and patching, plus persistent storage outside the game server. Unity's own fleet service has been withdrawn; see the hosting row on Unity Multiplayer Services. A backend for accounts and data is covered in Live services.

Rules

NETSTACK-SIZED-BY-SESSION — pick the stack from the expected players per session and the authority model, and write both numbers down. Check: the project's network design records players per session, topology, authority and the source used for the stack's fit (one of the links on this page).
NETSTACK-NO-INVENTED-CAPACITY — a capacity figure in a design document cites an official page or a load test you ran. Where a vendor publishes no number, record "no official figure" and the plan to measure it. Check: every player-count or CCU number in the design links to its source or to a load-test record.
NETSTACK-ONE-PER-PROJECT — one netcode framework per project. Unity's Multiplayer Services docs state you can use only one of Netcode for GameObjects or Netcode for Entities per project (Sessions tutorials); mixing third-party frameworks multiplies the same conflict. Check: Packages/manifest.json and the Assets folder contain exactly one netcode framework.