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.
| Area | Screens | Actions | API | Records | What it covers |
|---|---|---|---|---|---|
| Database | 47 | 173 | 41 | 24 | Managing the Postgres database itself: schemas, tables, functions, triggers, indexes, roles, extensions, publications, replication and backups. |
| Project Settings | 44 | 82 | 72 | 13 | Project-level configuration: general settings, compute and disk add-ons, API keys, JWT signing keys, infrastructure and read replicas, log drains and… |
| Project | 90 | 61 | 28 | 6 | A single Supabase project — the database and its services — and every tool the dashboard offers for working on it. |
| Project Integrations | 32 | 85 | 4 | 10 | Postgres-side integrations installed into a project: cron jobs, queues, vault, foreign-data wrappers, GraphQL and the integrations marketplace. |
| Authentication | 43 | 58 | 20 | 6 | Configuring the project's Auth service: end users, sign-in providers, email templates, MFA, sessions, rate limits, hooks and RLS policies. |
| Storage | 25 | 46 | 39 | 7 | Buckets and their contents — file, analytics and vector buckets — plus storage access policies, S3 credentials and storage settings. |
| Billing & Subscription | 27 | 33 | 27 | 6 | Plan and subscription changes, payment methods, billing address and tax IDs, invoices and credits for the organization. |
| Table Editor | 32 | 53 | 0 | 4 | The spreadsheet-style editor for table rows and schema: creating and altering tables, columns and foreign keys, and editing data in the grid. |
| SQL Editor | 23 | 32 | 14 | 2 | Writing, running and saving SQL against the project's database, with snippets, templates and quickstarts. |
| AI Assistant | 7 | 42 | 12 | 1 | The in-dashboard AI that answers questions, writes and explains SQL, and proposes schema and policy changes against the current project. |
| Branching | 15 | 21 | 20 | 2 | Preview branches of a project and the merge requests that promote their schema changes back to production. |
| Account | 11 | 26 | 16 | 4 | The signed-in person's own settings: profile, security and MFA factors, personal access tokens, and their account audit trail. |
| Logs | 34 | 14 | 3 | 1 | Querying the project's log streams — Postgres, API, auth, storage, edge functions, pooler, cron — through preset views and the Logs Explorer. |
| Observability | 21 | 18 | 5 | 5 | Charts and reports on how the project is behaving: API, database, auth, storage and edge-function metrics, plus query insights and performance. |
17 paths are described in the model; the longest 12 are here, with how many areas each one crosses.
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…
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…
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…
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…
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…
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…
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…
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…
Setting up analytics replication: Pipelines is enabled, a destination is defined and validated against the warehouse, a publication decides which tables travel, and the…
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…
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…
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…
16 rules are described; each one watches a record and changes something else when it moves.
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.
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.
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…
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…
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…
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…
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 invoice left open escalates: first a warning, then a grace period, then services actually restricted. It also blocks specific operations elsewhere — deploying a read…
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
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 →
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.
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.
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.