---
title: "Networking stacks by game size: NGO, Netcode for Entities, Mirror, FishNet, Photon"
slug: /workflows/netcode-stack-choice/
markdown: /workflows/netcode-stack-choice.md
section: netcode
tier: 2
summary: "Which framework fits which game size and topology, with each scale claim tied to its official source."
sources: ['Official Unity, Mirror, FishNet and Photon docs, read 15 Oct 2026']
canonical: https://unityworkflowlibrary.dev/workflows/netcode-stack-choice/
read_first: /read-first.md
---

> Read first, on every prompt: [non-destructive rules](/read-first.md).

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

> Which framework fits which game size and topology, with each scale claim tied to its official source.

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](/workflows/networking-overview/). 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](/workflows/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](https://docs.unity3d.com/6000.2/Documentation/Manual/multiplayer-overview.html)).
- **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](https://docs.unity.com/en-us/multiplayer/netcode/netcode)). 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](https://docs.unity.com/en-us/multiplayer/netcode/netcode), [multiplayer overview](https://docs.unity3d.com/6000.2/Documentation/Manual/multiplayer-overview.html)). 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](https://mirror-networking.gitbook.io/docs/manual/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?](https://fish-networking.gitbook.io/docs)); 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](https://dev-doc.photonengine.com/fusion/current/fusion-choose)). 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](https://www.photonengine.com/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](https://doc.photonengine.com/pun/current/getting-started/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](/workflows/dots-overview/).
- **Mirror:** pick it when you want an open-source, server-authoritative GameObject library with interest management built in and transport choice. Rules: [Mirror networking](/workflows/mirror/).
- **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](https://mirror-networking.gitbook.io/docs/manual/interest-management)); Netcode for Entities documents ghost and snapshot optimisation ([Optimize performance](https://docs.unity3d.com/Packages/com.unity.netcode@7.1/manual/optimizations.html)).
- **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](/workflows/unity-multiplayer-services/). A backend for accounts and data is covered in [Live services](/topics/live/).

## 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](https://docs.unity.com/en-us/mps-sdk/build-sessions-landing)); mixing third-party frameworks multiplies the same conflict. Check: `Packages/manifest.json` and the Assets folder contain exactly one netcode framework.