Bring Supabase usage into the portfolio view.

Every Supabase project is built around a real PostgreSQL database, so the SQL you already know works normally. What makes Supabase different from a plain database host is everything bundled around that database: an auto-generated REST and realtime API, authentication, file storage, and edge functions all share the same project.

That bundling is convenient, and it is also the single biggest reason novices misread their usage. A Supabase project produces several unrelated kinds of consumption, and they are not interchangeable. Understanding which number means what is most of the battle.

• Database size — the bytes your PostgreSQL tables, indexes, and internal structures occupy. This is the number people usually mean when they say “my database is getting big.”
• Storage — files uploaded to Supabase Storage buckets (images, PDFs, uploads). These live outside PostgreSQL and are billed as their own category.
• Egress — bytes leaving the platform toward your users and services. Downloading a large file repeatedly generates egress without growing your database at all.
• Requests — the count of API calls hitting your project. A count of calls is not a measure of bytes, and neither one predicts the other.
• Compute — the instance size allocated to your project's database. On Supabase this is an allocation you choose, not a meter that drops to zero when idle.

Almost every surprise Supabase bill traces back to one of a handful of patterns, and all of them are easy to check once you know they exist.

• Serving images or files straight from the client on every page load. Files do not shrink your database, but each download is egress. Caching and correctly sized images matter more than most query tuning.
• Selecting entire tables from the browser. A convenient select("*") without filters or pagination pushes far more bytes over the wire than the user ever sees.
• Realtime subscriptions left open. Broad subscriptions keep pushing changes to clients that stopped caring, quietly generating traffic all day.
• Tables that never stop growing. Logs, events, webhook payloads, and audit rows accumulate forever unless something deletes them, and indexes grow along with them.
• Forgotten projects. A staging project from a launch six months ago still holds an allocation and still counts.

PostgreSQL allows a limited number of simultaneous server connections, and smaller Supabase instances allow fewer than people expect. Serverless functions make this worse, because each cold invocation can open its own connection and nothing coordinates them.

Supabase publishes separate direct, session-pooler, and transaction-pooler connection strings for exactly this reason. Serverless and highly concurrent clients generally want the transaction pooler; migrations and long-lived administrative sessions generally want a direct connection. Copy the exact string from the Supabase dashboard rather than editing a hostname or port by hand — PostgreSQL connection pooling explained walks through the differences.

If your app intermittently fails with connection errors under load, that is the usual culprit, not a slow query. Idle in transaction sessions covers the related case where connections are held open by code that forgot to commit.

You do not need a dashboard obsession. You need to notice change early enough to act cheaply.

• Compare database size against last week, not against an absolute limit. Direction matters more than the current value.
• Check which tables are largest and whether the biggest one is supposed to be the biggest one.
• Look at egress separately from database size, since they move for completely different reasons.
• Scan for projects you no longer recognize before assuming all usage is legitimate.
• Estimate the effect of a change before making it with the Supabase usage calculator or the egress calculator.

DatabaseMeter connects using a Supabase personal access token that you create and can revoke. It is validated on the server, encrypted before storage, and never shown again. Collection is read-only and does not modify your projects, data, or settings.

Where Supabase's Management API does not expose a compatible value — project-level egress bytes being the most common example — DatabaseMeter marks the metric unavailable. It will not substitute a request count, borrow a related number, or display zero to fill the gap, because a wrong number is more damaging than a missing one.

Supabase's dedicated compute allocation is also kept distinct from Neon's scale-to-zero compute usage. They are genuinely different billing models, and flattening them into one chart would be misleading. The Neon vs Supabase comparison explains where the two models diverge, and the free PostgreSQL health check gives you a one-off read on a database without creating an account.