Supabase: a Postgres platform assembled from open source tools

The problem Supabase solves, and who it is for

Building a product on Postgres normally means assembling several separate concerns yourself. You need a REST or GraphQL layer over your tables, an authentication service that issues and validates tokens, a websocket channel for live updates, and somewhere to put files with permissions that match your database rules. Supabase's stated aim is to give developers a Firebase-like experience while keeping Postgres as the database. The README puts it plainly: "We're building the features of Firebase using enterprise-grade open source tools."

That framing matters for who should care. If your team already writes SQL and wants row-level security to be the place where authorization lives, this is aimed at you. If your team wants to avoid thinking about schemas, migrations and connection limits, the same design will feel like overhead. The README also notes that Supabase is "not a 1-to-1 mapping of Firebase", which is a useful warning against assuming a drop-in replacement.

How the pieces fit: Postgres at the centre, services around it

The architecture described in the README is a set of independent servers pointed at one Postgres instance. PostgREST turns the database directly into a RESTful API, which means your table and view definitions are the API surface. GoTrue is described as a JWT-based authentication API for sign-ups, logins and session management. Realtime is an Elixir server that listens to Postgres replication, converts changes to JSON and broadcasts them over websockets to authorized clients. Storage is a RESTful API that manages files in S3 while Postgres handles permissions. pg_graphql exposes a GraphQL API as a Postgres extension, and postgres-meta is a RESTful API for managing the database itself, used by the dashboard. Envoy sits at the edge as the proxy in front of these services.

The consequence of this layout is that authorization is not duplicated per service. Because Storage defers permissions to Postgres and PostgREST derives its API from the schema, policies written in SQL apply across the surface. That is the main architectural bet, and it is also the main source of friction: the moment you want behaviour that Postgres policies cannot express, you are working against the grain rather than with it.

Getting the stack running locally

The README does not give install commands. It points to supabase.com/docs for full documentation, and to the guides for self-hosting and local development. The repository carries a supabase/ directory and a docker/ directory, which is where the local stack is defined, and the CLI is the entry point the documentation describes. Check the documentation site for the current install method for your platform rather than copying a command from a blog post.

The repository's package.json shows how the workspace itself is driven. It enforces pnpm before anything else installs:

"scripts": {
  "preinstall": "npx only-allow pnpm",
  "build": "turbo run build",
  "dev": "turbo run dev --parallel"
}

That is the monorepo's own tooling, not the end-user CLI, and the distinction matters if you intend to contribute rather than consume. The README directs contributors to DEVELOPERS.md for how to get started. If you only want to run the platform, the documentation's local development guide is the path, and the docker/ directory is what backs it. The README does not document a rollback or teardown procedure for a local stack, so plan for that gap before you rely on it in a shared environment.

The client library split, and why it affects your upgrade path

The README describes the client library approach as modular: "Each sub-library is a standalone implementation for a single external system." The repository table lists official clients for JavaScript and TypeScript (supabase-js, with postgrest-js, auth-js, realtime-js, storage-js and functions-js bundled underneath) and for Flutter (supabase-flutter with postgrest-dart and gotrue-dart).

This modularity is a real benefit when you only want one piece, since you can depend on a sub-library directly. It is a cost when you upgrade, because the bundled client and the underlying sub-libraries version independently, and a change in the auth or realtime layer can surface through the umbrella package. The README's table is the authoritative list of what is official; anything not in it is community-maintained, and the README does not make promises about those.

Where the model breaks down

The first limitation is operational. Self-hosting means running Postgres, PostgREST, GoTrue, Realtime, Storage, postgres-meta and Envoy, and keeping them compatible with each other. The README lists self-hosting and local development as supported paths but does not describe an upgrade procedure for a self-hosted deployment, and the repository's release notes are titled "Developer Update", which suggests they are not a changelog for the server components. If you self-host, treat version pinning as your responsibility.

The second limitation is conceptual. Because the REST API is generated from the schema, exposing a table broadly is a schema decision, not a route decision. Teams used to writing explicit handlers for each endpoint will find that the default is more exposure than they expected, and that row-level security is the only thing standing between a table and the internet. That is a defensible design, but it demands that you write and test policies before you ship, not after.

The third is that Supabase is the wrong tool when you want a single runtime. Edge Functions exist, but the README describes them as one item in a list of features, not as the primary compute model. If your application logic is a large server-side program, you are better served by a conventional backend with Postgres behind it.

Supabase vs Firebase, and what the difference actually is

The comparison is unavoidable because the README invites it. The difference in approach is the database. Firebase's data model is a document store, and its security rules are a separate language evaluated by the platform. Supabase's data model is Postgres, and its authorization is SQL policy evaluated by the database, with PostgREST, Storage and Realtime all deferring to it. That means your authorization logic is portable: it lives in the database, and you can inspect it with psql.

The trade-off runs the other way too. Postgres is relational, so schema changes are migrations and mistakes are harder to undo than editing a document shape. Firebase can be adopted by a frontend developer with no database background; the Supabase stack assumes you are comfortable with tables, foreign keys and policies. Choose based on which of those two costs your team is better equipped to pay.

Licence, maintenance and what an upgrade costs

The repository is licensed Apache-2.0, and the README states the project's policy of using tools with an MIT, Apache 2, or equivalent open licence, building and open sourcing its own where none exists. That policy is why the components are separately licensed projects rather than one monolithic codebase, and it means your licence obligations depend on which components you deploy. Review the licence of each service you run; this is not legal advice.

The repository is not archived, and the last push was on 2026-08-07, so the codebase is being worked on. The recent releases are monthly developer updates rather than semantic versions of the platform, which tells you the release notes are not a substitute for tracking the individual components. Budget upgrade time accordingly: a self-hosted deployment has as many upgrade surfaces as it has services.

Editorial conclusion

Adopt Supabase if you want Postgres as the source of truth and are willing to learn its auth and row-level security model. Skip it if you need a single-language runtime or cannot operate Postgres. Before committing, verify that the self-hosted path in supabase/docker gives you the services you depend on, and that the client library you plan to use is listed as official in the README table.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes