Pylon vs. Nakama

Nakama is Heroic Labs' open-source game server — a feature-complete Go binary with matchmaker, leaderboards, tournaments, and IAP receipt validation. Pylon overlaps significantly but biases toward declarative app data plus game shards in one tighter package.

Start free on Pylon Cloud →Read the docs →

TL;DR

Pick the one that fits your shape

Choose Nakamaif

You want a feature-complete game backend out of the box, you're shipping a F2P mobile game with leaderboards / tournaments / IAP / groups, and you have Go (or Lua / TS) game-server engineers.

Choose Pylonif

You want a single binary with both app data and game shards, your team is comfortable with Rust + TypeScript, you need declarative entities + faceted search, and you don't need every Nakama feature pre-built.

Architecture

Where the two diverge

	Pylon	Nakama
Runtime	Rust binary	Go binary
Backing DB	SQLite (default), Postgres	Postgres (required)
Match handlers	`Shard<S: SimState>` (Rust)	Go / Lua / TypeScript runtime
Storage	Declarative entities	Storage Engine (typed JSON blobs)
Live queries (non-game)	Yes	Via Storage Engine pull
Faceted search	Built-in (FTS5)	Not built in
Binary size	~30 MB	~100 MB

Same shape

What both ship

Either one is a real choice for a multiplayer game backend with built-in matchmaking. The differences below are about emphasis and operational shape, not feature presence.

Tick-based authoritative match handlers
Matchmaker with customizable algorithm
Built-in user accounts + sessions
WebSocket realtime
Notifications + friends
Single self-hosted binary
Open source

Where Pylon wins

What you get with Pylon you don't with Nakama

Declarative entities, not typed JSON blobs

Pylon's schema is first-class — indexes, relations, live queries flow naturally. Nakama's Storage Engine stores typed JSON with read/write permissions, but you don't get the entity + reactive query shape.

Live queries for UI

useQuery("FriendOnline") returns the live array. Nakama has Streams for pub/sub and the Storage Engine for persistence; neither gives you reactive arrays.

Faceted search in the binary

FTS5 + roaring-bitmap facets. Nakama has no FTS or facets — you'd integrate Algolia or Meilisearch.

Functions share a transaction with writes

Pylon's mutation / action runs in-process and shares a transaction with the entity write. Nakama's TS runtime is for match logic; CRUD goes through the Storage Engine API separately.

Single-language story

Rust runtime + TypeScript functions, everywhere. Nakama is Go (server) + your choice (Go / Lua / TS handlers) + SDK language. Polyglot is a feature for some teams and a complexity tax for others.

Fully OSS — no enterprise tier dark-pattern

Pylon is MIT/Apache end-to-end. Nakama core is Apache 2.0 but Heroic Cloud + Satori analytics are proprietary paid services. Apples-to-apples self-hosted, fine; if you're evaluating the managed offering, the licensing shapes differ.

Where Nakama wins

What Nakama does better today

Honest comparison — these are real reasons to pick Nakama. If any of them are dealbreakers, choose accordingly.

Wider out-of-the-box feature set for game-specific concerns

Leaderboards with reset schedules + regional variants + anti-cheat, tournaments with brackets, parties for pre-match groups, groups/clans with rank hierarchies, IAP receipt validation for App Store + Play Store + Steam, persistent notifications with read state. Pylon's primitives let you build these; Nakama ships them.

Mature game-server patterns

Written by Heroic Labs, used by Vela Games, PlayerUnknown Productions, and many others. Patterns for multi-region, console platforms, and esports tournaments are documented.

Multi-language match-handler runtime

Match logic in Go, Lua, or TypeScript. Pylon's match logic is Rust — fewer language choices but tighter performance.

Console platform patterns

PlayStation, Xbox, Switch integration patterns are documented and proven.

Migration

Coming from Nakama

Most of the dev surface translates one-to-one. The biggest deltas show up as differences in shape, not features missing.

Nakama	Pylon
Match handler (Lua / Go / TS)	`SimState::tick` in Rust
Storage Engine objects	Entities + policies
Leaderboards (built-in)	Entity + sort query (build your own primitive)
Tournaments (built-in)	Entity + scheduler (build your own primitive)
Streams pub/sub	Pylon pub/sub + presence
Friends / groups (built-in)	Custom entities
IAP receipt validation	Pylon `action` calling Apple/Google APIs
Notifications (built-in)	Custom entity + push provider integration

Honest weakness

Where Pylon loses

Nakama's feature set is genuinely deeper for game-specific concerns. If you need leaderboards-with-reset-schedules, tournaments-with-brackets, IAP validation, groups with rank hierarchies — those are real things you'd otherwise build yourself. Pylon's primitives let you build them, but Nakama hands them to you. For pure-game backends with deep social features, Nakama is often the right pick.

Both / and

When using both is the right call

Some studios run Nakama for the game backend and Pylon for the surrounding web/mobile app — account UI, billing, support tools, content management, marketing site. The two backends share user identity via OAuth or a shared SSO. Don't conflict, just different scopes.

Try Pylon — free Hobby tier on Cloud

No card, no setup. Run a real Pylon project against managed Postgres in under a minute. Migrate from Nakamawhen you're ready — or run both.

Start free on Pylon Cloud →