Published model · 2026-08-29

Supabase Studio architecture,
read from the code.

459,339 lines of source, 2,023 parts described, 34 areas and 17 customer paths. The dashboard behind a database platform. Every line on this page comes from the model — open it and check any of them.

In numbers

What the model holds.

459,339Lines of source read
2,023Parts described
34Areas
581Screens
892Actions
409API routes
112Records
189Services
17Customer paths
13Status flows
16Rules
243 of 409Endpoints on no described path
Areas

The 14 heaviest areas of 34.

AreaScreensActionsAPIRecordsWhat it covers
Database471734124Managing the Postgres database itself: schemas, tables, functions, triggers, indexes, roles, extensions, publications, replication and backups.
Project Settings44827213Project-level configuration: general settings, compute and disk add-ons, API keys, JWT signing keys, infrastructure and read replicas, log drains and…
Project9061286A single Supabase project — the database and its services — and every tool the dashboard offers for working on it.
Project Integrations3285410Postgres-side integrations installed into a project: cron jobs, queues, vault, foreign-data wrappers, GraphQL and the integrations marketplace.
Authentication4358206Configuring the project's Auth service: end users, sign-in providers, email templates, MFA, sessions, rate limits, hooks and RLS policies.
Storage2546397Buckets and their contents — file, analytics and vector buckets — plus storage access policies, S3 credentials and storage settings.
Billing & Subscription2733276Plan and subscription changes, payment methods, billing address and tax IDs, invoices and credits for the organization.
Table Editor325304The spreadsheet-style editor for table rows and schema: creating and altering tables, columns and foreign keys, and editing data in the grid.
SQL Editor2332142Writing, running and saving SQL against the project's database, with snippets, templates and quickstarts.
AI Assistant742121The in-dashboard AI that answers questions, writes and explains SQL, and proposes schema and policy changes against the current project.
Branching1521202Preview branches of a project and the merge requests that promote their schema changes back to production.
Account1126164The signed-in person's own settings: profile, security and MFA factors, personal access tokens, and their account audit trail.
Logs341431Querying the project's log streams — Postgres, API, auth, storage, edge functions, pooler, cron — through preset views and the Logs Explorer.
Observability211855Charts and reports on how the project is behaving: API, database, auth, storage and edge-function metrics, plus query insights and performance.
Customer paths

What a person walks through, step by step.

17 paths are described in the model; the longest 12 are here, with how many areas each one crosses.

Change an organization's plan9 steps · 1 areas

Moving an organization between plans: priced with proration and tax, paid with a validated billing profile, and — downwards — stated in terms of what will actually be…

Take a change from a preview branch to production9 steps · 1 areas

The branching workflow end to end: a preview branch is created from production, changed, diffed, reviewed — with the assistant given both the diff and the production…

Create a project8 steps · 2 areas

From the creation form to a database that answers: the options that can never be changed afterwards are chosen first, the project is created, and it then walks its own…

Run a SQL query8 steps · 2 areas

A statement written in the SQL editor reaching the database: checked for the four things that go badly wrong, sent through the cost-gated executor as a chosen role…

Protect a table with a policy8 steps · 5 areas

The path from an exposed table to a protected one: RLS is enabled, a policy is written from a template or by hand, the generated statement is reviewed, and the result is…

Deploy and verify an edge function8 steps · 1 areas

A function reaching the edge and being proven to work: deployed from the dashboard or the CLI, invoked with a real authorization header from the tester, then watched…

Rotate the key that signs project tokens8 steps · 2 areas

Replacing the key without invalidating everyone's session: a standby key is created and published for verification, promoted so new tokens use it while the old key still…

Bring someone into an organization8 steps · 4 areas

An invitation and what it grants: sent singly or as a pasted batch, accepted into a role that may be organization-wide or scoped to named projects, and adjustable…

Replicate a database into a warehouse8 steps · 1 areas

Setting up analytics replication: Pipelines is enabled, a destination is defined and validated against the warehouse, a publication decides which tables travel, and the…

Configure a sign-in provider7 steps · 1 areas

Turning on a way for a project's users to sign in: the provider's fields come from its own declaration, the callback URL is copied into the provider's console, and the…

Diagnose a slow database7 steps · 3 areas

The diagnostic path a developer actually walks: notice it on the overview, find which queries are responsible, read the plan, and act — an index, or terminating whatever…

Decide what the Data API serves7 steps · 3 areas

The decision that governs everything reachable without a database connection: whether PostgREST runs at all, which schemas it exposes, and what inside them is safe to…

Rules

What the product enforces on its own.

16 rules are described; each one watches a record and changes something else when it moves.

Cancel listings when the folder changeswatches BucketObject · reaches BucketObject

Opening a different bucket or folder aborts the in-flight object listings, so a slow response for the previous folder cannot arrive and overwrite the new one.

Abort an upload batchwatches BucketObject · reaches BucketObject

Dismissing an upload toast runs the abort callbacks registered for that batch, so cancelling the notification actually stops the transfers rather than only hiding them.

A saved row edit refreshes the gridwatches TableRow · reaches TableRow · PGTable

When the queued edits are written, the table's rows and its estimated count are invalidated, so the grid shows what the database now holds rather than the optimistic…

Creating an index refreshes query performancewatches PGIndex · reaches IndexAdvice · Lint

An index created from the index advisor invalidates the query performance results, so the effect on the query that prompted it is visible immediately rather than at the…

A schema change rewrites the API documentationwatches PGTable · reaches PostgrestConfig · PGColumn

The project's documentation and its TypeScript types are generated from the OpenAPI spec PostgREST serves, so adding a column or a function changes them without anything…

Publication membership decides what Realtime carrieswatches PGPublication · reaches PGTable · PGPublication

Adding a table to the supabase_realtime publication is what makes its inserts, updates and deletes reach subscribed clients; removing it stops them. The toggle in the…

A full disk puts the database into read-onlywatches DiskAttributes · reaches Project · ResourceWarning

When used space approaches the provisioned disk, the project is put into read-only mode to protect it. Growing the disk alone does not lift it — the read-only state has…

An unpaid invoice restricts the organizationwatches Invoice · reaches Organization · Project

An invoice left open escalates: first a warning, then a grace period, then services actually restricted. It also blocks specific operations elsewhere — deploying a read…

Status flows

The states records move through.

Project · Project

Project status flow

Paused → Coming up → Healthy → Unhealthy → Going down → Pausing → Pause failed → Restoring → Restore failed → Restarting → Upgrading → Resizing → Provisioning failed → Removed → Unknown

15 states · 18 transitions

Branch · Branching

Preview branch status

Creating project → Running migrations → Migrations failed → Migrations applied → Functions deployed → Functions failed to deploy → Healthy → Unhealthy → Restoring → Removed

10 states · 13 transitions

ReadReplica · Project Settings

Read replica setup

Requested → Launching → Instance launched → Setup initiated → Base backup downloaded → WAL replayed → Completed → Failed

8 states · 11 transitions

Content · SQL Editor

SQL snippet status flow

New → Saving (first) → First save failed → Saved → Unsaved changes → Saving → Save failed

7 states · 12 transitions

ReplicationPipeline · Database

Replication pipeline state

Unknown → Stopped → Starting → Running → Stopping → Restarting → Failed

7 states · 14 transitions

JwtSecretUpdateStatus · Project Settings

JWT secret rotation

Started → API services configured → Admin API configured → Gateway configured → Postgres restarted → API services restarted → Failed

7 states · 10 transitions

What the model says about itself

Answers nobody wrote down.

Computed from the model’s own connections, with the count behind each one.

How much of this product is built but unused?

59% of this product's API surface is dark: built and paid for, but part of no described customer path and consumed by no screen.

243 OF 409 ENDPOINTS · READ FROM 17 CUSTOMER PATHS DESCRIBED SO FAR

Where is it riskiest to make a change?

The riskiest place to change is “Database”: more of the product depends on PGTable than on anything else.

30 INBOUND DEPENDENCIES · COMPUTED FROM THE REACH GRAPH, NOT ESTIMATED

Where did the engineering effort actually go?

The deepest engineering investment is “Database” — 14% of the product's mass. “Organization Settings” is compact and self-contained: the cheapest place to change.

287 VS 5 OBJECTS · CHANGE-COST RATING = SIZE × CROSS-DOMAIN COUPLING

Which customer experience breaks first?

The most fragile customer experience is “Protect a table with a policy”: it crosses 5 domains in 8 steps — the first place integration breaks.

INTEGRATION-TEST PRIORITY №1 · DOMAINS COUNTED PER PATH STEP

Ask the model your own question →How these answers were scored →

Questions

About this model.

How was this Supabase Studio architecture built?

GitMir read the public repository and established what the product does: its areas, screens, actions, API routes, records, customer paths, status flows and rules, with every statement traceable to the source it came from. Nothing on this page is written by hand; it is the published model, as of 2026-08-29.

Is it current?

This page is a snapshot of the published model. On a connected repository the model is updated as commits land, so people and AI agents work from the product as it is now rather than as it was when somebody last wrote it down.

Can I get this for my own repository?

Yes — connect a repository and GitMir builds the same thing for it: features, rules, customer paths and how they connect, available to people on the screen and to coding agents over MCP.

OpenAI Codex architecture →cal.com architecture →

Get this for your
own product.