Comparison
Supabase
Supabase was founded in 2020. While not specifically a game backend, it is a rising choice for game developers due to its ease of use and flexibility.
What Supabase does well
- Open-source (Apache 2.0)
- Tightly integrated with PostgreSQL
- Realtime
- Easy to use UI & API
- Quick to get started
How Supabase and Open Game Backend are similar
- Open-source (Apache 2.0)
- Built on top of PostgreSQL
- Built on Deno
How Supabase and Open Game Backend differ
Secure by default
Games are notorious for the amount of DDoS & botting attacks launched against them. Security needs to be considered early on when developing your backend. Supabase Supabase Database is designed to let developers iterate quickly, but leaves security as an afterthought. A few key points:- Your database is exposed publicly by default without well configured RLS policies. Many developers miss this key point or have trouble using RLS correctly.
- Rate limiting is effectively non-existent. Currently, you have to reverse engineer their API and set up a reverse proxy in front of Supabase in order to implement rate limiting. This adds latency, complexity, and a heavy time commitment.
- Captchas are only available for auth endpoints and cannot be enabled for other sensitive scripts without manually writing this yourself in an Edge Function.
- Many developers with mature products on Supabase end up needing to completely rewrite their database logic on the backend to explicitly handle security concerns. Edge Functions are built for this use case, but they’re still maturing. (1 2 3)
- All logic is forced to be a server-side script. Never trust the client.
- Database & scripts are private by default, explicitly specify what’s public.
- Granular rate limiting (per account and/or per IP) is provided out of the box.
- Captchas are available for all use cases.
- Strict schemas are enforced on all requests.
Modularity
Supabase Supabase is built to be a general purpose backend framework. Backend code is not meant to be published as reusable packages or shared across multiple games within a studio. Open Game Backend Open Game Backend is a combination of two components:- OpenGB Engine Abstracts away backend complexity to make writing modules simple & fast
- OpenGB Module Registry Pre-made modules that can be used to get up and running instantly
Supabase Edge Functions vs OpenGB Scripts
Supabase Supabase Edge Functions are similar in some ways to Open Game Backend’s scripts. Both are built on Deno, backed by PostgreSQL, and requests are ephemeral + isolated. Supabase Edge Functions are intended to be used for simple serverless functions. Most use cases today are for handling a patchwork of functionality that isn’t provided by Supabase by default (e.g. webhooks, push notifications, Discord API calls). Edge Functions still behave like an experimental pre-release feature. Open Game Backend Open Game Backend scripts are at the core of the project, so they’re built to be easy to use, flexible, and reliable. They’re used to power core functionality such as tokens, authentication, and rate limiting.Rigid Core Features vs Flexible Modular Features
Supabase Supabase provides core functionality that cannot be modified, such as: authentication, storage, and realtime. Open Game Backend Open Game Backend instead provides these same features as modules that can be modified & extended as needed. For example: authentication and storage modules. These can be customized easily by running theopengb fork command.
For example, this is specifically important for games where authentication with platforms like Steam, consoles, and instant gaming platforms don’t fit well with Supabase’s core authentication features.