Nakama vs Photon

This is intended to be a brief, objective, technical overview of Nakama and Photon

At a very high level

Multiplayer Engine

Nakama

Turn-based and realtime. The engine itself is realtime and works as a message broker. Turn-based games have their state managed in-memory on the server. The server can also be switched into authoritative mode with a game loop in Lua managed per match.

Photon Server

Turn-based and Realtime. The engine is realtime, it works like a message broker with different limits set for Turn-based games. Server authoritative code can be written in C++ or C#. It’s unclear how game state is managed by the server.
Turn Data Persistence

Nakama

Yes.

Photon Server

No. Like a message broker messages are delivered to all connected participants. If a participant drops their connection there is no built-in way to re-sync.
Automatic Matchmaking

Nakama

Yes.

Photon Server

Not available in the on-premise server.
Manual Matchmaking

Nakama

Yes.

Photon Server

Arbitrary room lists and filters.
In-game Chat

Nakama

1 on 1, group, and room-based chat. Available as part of Nakama server and can be self-hosted.

Photon Server

Not available in the on-premise server.
Chat History

Nakama

Persistent chat history, can be kept as long or short as required by the studio.

Photon Server

Ephemeral chat history with a temporary message buffer.
Hosted

Nakama

Any cloud of your choice, local or bare metal.

Photon Server

Windows-only VMs and local or bare metal.
Self-Hostable

Nakama

Windows, macOS, and Linux.

Photon Server

Windows only.
User Identification

Nakama

The service has built-in support for many different login options including reliable unique identifiers and email/password accounts. You can also connect the user via Facebook or Google accounts.

Photon Server

Requires external solution. The multiplayer service does not provide any way to reliably identify players. This must be handled separately through custom service integrations, and requires special consideration on the client side.
Match Persistence

Nakama

All matches are persisted by the service. Clients can access matches at any point until they end, or the client opts to leave the match. Match state with multiplayer matches can be suspended and resumed via custom functions.

Photon Server

Rooms have no built-in persistence. Custom external integrations may be provided to persist room data on a message by message basis. There is no built-in mechanism to allow clients to find and rejoin a room if they’ve disconnected for any reason.
Transport Protocol

Nakama

WebSocket, secure rUDP, WebRTC.

Photon Server

Sync Behaviour

Nakama

Data is pushed to clients over a background socket. Data is persisted by the server, and state is tracked, so clients losing network connectivity can rejoin at a later point.

Photon Server

Mandatory polling callback expected to be triggered at least 10-50 times per second. Failing to maintain expected rates can lead to client disconnects. Because rooms are stateless, clients re-joining rooms after connection loss cannot catch up, by default.
Open Source

Nakama

Fully open source server.

Photon Server

Closed source.