Nakama vs Firebase
This is intended to be a brief, objective, technical comparison of Nakama and Firebase.
If you feel this comparison is unfaithful for whatever reason, please send an email to email@example.com
At A Very High Level
- Heroic Labs' Nakama is an open-source server which can be hosted on any cloud as well as locally. Firebase is a proprietary SaaS service hosted in the cloud and cannot be self-hosted.
- Nakama server and the client libraries are open source on GitHub. Nakama can be run on Windows, macOS, and Linux for development and production.
- Nakama comes packaged with a database to provide a fully capable collection of services. No separate solutions are required for user accounts, social login, data storage, etc.
- Firebase comes with a realtime data storage system which automatically syncs data between server and client. It also has a large object storage (for photos, videos and other assets) that uses cold-line storage as the backing mechanism.
- Nakama handles persistent users and shared state as well as persistent chat history. Firebase does not have any higher order functionality (like built-in chat and presence system).
- All of Nakama’s features: Realtime multiplayer, chat, matchmaker, server authoritative logic, etc. are available with the same server and license. Licenses for Nakama Enterprise (for multi-server clusters) includes all features and no artificial CCU limitations.
- Firebase provides Performance Monitoring, Crash Reporting, Analytics for free. All other development tools (such as Realtime Database) are paid products.
The table below gives a high level comparison of Nakama's Managed Cloud and Firebase platform. To keep the page relevant in the face of rapid development on both sides, low level details are found in links to the online documentation for Heroic Labs and Firebase.
|Feature/Capability||Managed Cloud (Nakama)||Firebase|
|User Identification||Nakama offers multiple methods to authenticate, including email/password, third-party providers like Google or Facebook, or using existing account systems. This also includes game servers like Steam and GameCenter.||Firebase Auth offers multiple methods to authenticate, including email/password, third-party providers like Google or Facebook, or using existing account systems. Optional UI element available.|
|Data Storage||Nakama can store read-only, private and public data in JSON format in a postgres-compatible database. Each record has specific read-write permissions, and based on the permissions you can fetch or list records across buckets/collections/users. The Storage API also allows for JSON-patch operations to atomatically update data. All operations are batched and they have transaction guarantees.||The Firebase Realtime Database stores JSON application data, like game state, and synchronizes changes instantly across connected devices. Firebase apps remain responsive even when offline because the Firebase Realtime Database SDK persists your data to disk. Once connectivity is reestablished, the client device receives any changes it missed.|
|Asset Storage||Nakama doesn't store asset files directly. Instead you can store a version-specific manifest which lists all files and the link to download the files from cold-line storage such as an S3 bucket from AWS for over-the-air updates.||Firebase Storage stores and serves user-generated content, such as photos or videos. Firebase SDKs for Cloud Storage perform uploads and downloads to Firebase Storage servers.|
|In-app Chat & Chat History||1 on 1, group, and room-based chat. Available as part of Nakama server and can be self-hosted. Persistent chat history, can be kept as long or short as required by the studio.||Not available.|
|In-app and Push notifications||Nakama pushes system notifications to the devices that are online automatically (for instance when a user accepts friend request). You can send custom notifications and optionally persist them for later delivery. Push Notification is built-in as a Lua module.||Firebase provides Push Notifications via Firebase Cloud Messaging platform (FCM) which is built on Google Cloud Messaging. You can segment users and send mass notifications, but notifications are not persisted for later delivery.|
|Remote Configuration||You can use server-side code to represent the in-app parameters as a static variable, or alternatively store the configuration settings in the storage engine as a read-only record. You can read more about it here.||Firebase Remote Config includes a client library that handles important tasks like fetching parameter values and caching them. Your app gets service-side values using this client library which in turn fetches the data from the server.|
|Matchmaking & Multiplayer Engine||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.||Firebase does not have any multiplayer capabilities.|
|Transport Protocol||Websocket (rUDP coming soon)||Websocket|
|Sync Behaviour||Data is pushed to clients over a background socket. Data is persisted by the server, and state is tracked. If client lose network connectivity, they can then rejoin at a later point.||Data stored in the Firebase Realtime Database is pushed to the clients as soon as available on the server. Authentication, asset storage, etc use request-response model.|
|Hosted||Any cloud of your choice, local or bare metal. We also offer a Managed Cloud for developers who do not wish to operationalise their own infrastructure.||Hosted on Google servers, and cannot be self-hosted.|
|Open-source||Fully open-source server.||Closed source.|