docs: add backend internal docs (#400)

docs/backend/comparison/nakama.mdx

@@ -0,0 +1,70 @@
+---
+title: Nakama
+---
+
+<Note>
+  Please read Open Game Backend's [roadmap](/docs/roadmap) for known limitations.
+</Note>
+
+[Nakama](https://heroiclabs.com/nakama/) was founded in 2014 and is still an independent company.
+
+## What Nakama does well
+
+- Open source (Apache 2.0)
+- LiveOps features provided by Satori (closed-source)
+- Written in Go
+- Focus on real-time multiplayer games
+- Provides scripting in TypeScript, Go, and Lua
+
+## How Supabase and Open Game Backend are similar
+
+- Open-source (Apache 2.0)
+- Self-hostable on any cloud provider
+
+## How Nakama and Open Game Backend differ
+
+### Prefab backend vs modular backend
+
+**Nakama**
+
+Nakama provides a predefined set of features out of the box. While you can fork Nakama to extend it with your own features, it has a high learning curve & requires you to run your own servers.
+
+Nakama encourages developers to [use scripting to create RPCs and hooks](https://heroiclabs.com/docs/nakama/server-framework/introduction/index.html) to extend the server. While scripting support is extensive, it's still constrainted to Nakama's limitations.
+
+This means Nakama has first-class services written in Go and asks you to write second-class code written in a scripting language without access to a mature database.
+
+**Open Game Backend**
+
+Open Game Backend is designed from the ground up to be modular at its core. It provides a set of official modules to get you started quickly, but the primary use case is to extend the server with your own modules. All modules are first-class citizens have access to a mature database.
+
+### Scripting persistence
+
+**Nakama**
+
+Nakama provides persistence through its [storage engine](https://heroiclabs.com/docs/nakama/concepts/storage/) built on top of CockroachDB. The storage engine is a document store similar that stores JSON objects along with access controls. It also provides a well-designed mechanism for indexing data that prevents slow queries. The engine supports atomic & conditional writes, but does not support full transactions.
+
+**Open Game Backend**
+
+Open Game Backend modules are provided the full flexibility of PostgreSQL, including transactions, complex queries, and indexing. Unlike the Nakama storage engine, PostgreSQL enforces a strict schema on your data which makes it easier to assert the correctness of your data. PostgreSQL provides a [large collection of extensions](https://neon.tech/docs/extensions/pg-extensions) for managing many complex data types. PostgreSQL also integrates natively with many existing tools, such as SQL clients, BI tools, and data warehousing tools which are important when your game grows.
+
+### Cost
+
+**Nakama**
+
+Nakama provides a managed cloud [starting at {"$"}600 per month](https://heroiclabs.com/pricing/). However, running a high-availability cluter starts at $1,000 per month, which is required for any production deployment. Nakama's traditional server architecture requires beefy machines and doesn't scale to meet demand easily. Nakama can be self-hosted on your own server if you're willing to manage it yourself.
+
+**Open Game Backend**
+
+Open Game Backend can be hosted on serverless JS platforms (Cloudflare Workers, Deno Deploy) which can cost as little as penies per month and blitz scale to meet demand as needed. Open Game Backend can also be self-hosted on traditional web servers.
+
+### Go vs TypeScript
+
+**Nakama**
+
+Nakama is written in Go, while Open Game Backend is written in TypeScript. Both projects have different goals which lead to this choice.
+
+Go is a mature language for building high-performance servers. Nakama has a focus on running multiplayer servers within the server, so Go's performance is important. However, it's not as easy to learn as TypeScript.
+
+**Open Game Backend**
+
+TypeScript was chosen intentionally for Open Game Backend to make it dead simple to write & modify modules. TypeScript is not as fast as Go, but the performance gains are negligible since most overhead is spent waiting for the database.