You check Supabase to see how many people signed up overnight. Then Stripe to see how many paid. Then you do the division in your head, and forget it by lunch.
What the board shows
Your signups as a number that climbs, right next to the revenue it turns into.
Supabase’s MCP server lists your tables with how many rows each one has. Point at the table your signups land in, profiles or whatever yours is called, and the board shows its row count as a live number. Each time the board reads, the number gets a new point, so the line under it grows from the day you add it.
Put Stripe’s MRR or Lemon Squeezy beside it and the whole funnel is one glance. Add a goal and a ring shows how far you are from 2,000 users.
The same sign-in shows your projects and Supabase’s security and performance advisors. A table left without row level security shows up in a list you’ll actually see, not on a page you visit twice a month.
Where the numbers come from
Supabase runs its own MCP server, and the board signs in to it with Supabase’s own login. The sign-in is sealed on the board’s server.
The row count is the estimate Postgres keeps for each table, not a fresh count(*), so a small gap from an exact count is normal.
The board never runs SQL. Supabase’s server has a tool that runs any query you give it, and the board leaves it alone, along with everything else that could change your project. It only runs tools that read.
Want a number only SQL can give, like signups this week by plan? Send it from a cron job or a GitHub Action with the board’s push API, and it lands on the same board.
Supabase’s dashboard and this one
If you came here for Supabase’s own dashboard, that’s at supabase.com/dashboard. It’s where you run the project.
Context Board is where you see the business. Signups from Supabase, revenue from Stripe, traffic from Plausible, errors from Sentry, all on one board you arrange, for $6 a month.