Why your Supabase bill is climbing and how to find the queries behind it

What should be true before you start?

Understand what Supabase actually charges for: compute — your instance size multiplied by the hours it runs — not a per-row fee. So the number to watch is not a dollar tag on each query; it is the read load, the rows your queries return, because that load is what pushes you to a bigger, costlier instance.

Read cost is a measurement problem before it is an optimization problem. You cannot cut what you cannot attribute, and a database bill is a single total with no memory of which feature, screen, or background job spent it. The first job is to make the reads legible — grouped by the part of the product that caused them — so the expensive path is obvious instead of theoretical.

• Know that Supabase billing is compute-based, so rows read is the load signal, not a bill.
• List the endpoints and jobs that run the heaviest SELECTs.
• Decide the feature names you want rows-read grouped under.

How do you find where the reads go?

Because Supabase runs Postgres, one adapter covers it through the standard pg driver — the same adapter that covers Neon, Vercel Postgres, and RDS. It counts the rows each SELECT returns, attributed to the bucket that ran it, observing the result already in hand so it adds no load of its own.

The honest version of this measures the work already in hand. A good read meter counts the documents or rows a query already returned — it never runs an extra query, an EXPLAIN, or a profiler scan to measure, because a cost tool that itself costs reads is worse than none. Counting stays in memory, and attribution rides on the name you gave the path.

• Install the Postgres meter by passing your pg Client class.
• Wrap a heavy endpoint in bucket("billing-page", ...) so its rows-read group under that name.
• Let the meter count the rows every SELECT returns automatically.
• Rank features by rows read; the heaviest is where your compute is going.
• Narrow that query — filter, paginate, or index — and confirm the bucket falls.

import { installPgMeter, bucket } from "@cross-deck/buckets"
import { Client } from "pg"

installPgMeter({ Client }) // counts rows each SELECT returns

await bucket("billing-page", () =>
  pool.query("SELECT * FROM invoices WHERE user_id = $1", [id]))

Where do teams get this wrong?

The mistake is hunting for a per-query dollar figure that does not exist, instead of cutting the read load that actually moves the compute bill.

Most read-cost surprises are not one greedy query; they are an unattributed one. A scheduled job that re-reads a collection every few minutes, a dashboard that re-scans on every refresh, or a listener that fans out on each change can outspend every user-facing feature combined — and none of it shows up until you group the reads by cause and one bar dwarfs the rest.

• Treating Supabase like a per-row biller and looking for a price tag on each query.
• Optimizing a fast query while a SELECT * elsewhere returns ten times the rows.
• Upgrading the instance to absorb load that a single filter would have removed.

How does Crossdeck Buckets surface this?

Crossdeck Buckets measures the data work, not a guessed bill: rows read by feature, the raw load behind your compute. It names Supabase, Neon, Vercel Postgres, and RDS as the deployments it covers, because they all speak the same pg driver.

So when your Supabase bill climbs, you stop guessing. You open the buckets, see which query returns the most rows, and narrow that one — the compute follows the load down.

This is also the upgrade path, and it stays free across the step. The open-source collector shows the reads on one surface, grouped by the buckets you named — no account needed. Sign up to Crossdeck and a single SDK install adds the dimension the collector alone cannot see: which environment each read ran in — your server, your web app, your dashboard, or a mobile build — folded into the same buckets, still free. A spike stops being a guess between “is it the backend or the client?” and becomes a labelled segment you can read at a glance.

What should a healthy setup let you do?

After instrumenting, you should be able to open one view and name the top three features by read load, point to the single path driving the biggest bar, and say which environment it ran in. If that still takes a spreadsheet and a guess, the setup is not finished.

A healthy setup also makes the next change cheap to verify. Shipping an index, a cache, or a narrower query should move a specific bucket down — and you should be able to see that it did, not infer it from next month’s invoice.

• Rank features by read load and find the biggest single path.
• See which environment a read ran in — server, web, dashboard, or mobile.
• Confirm a fix moved the right bucket down, not just the bill as a whole.

What should you review after it is running?

Review the biggest bucket first — the single largest source of reads is almost always where the cheapest win lives. Then look for the rhythm that does not match your users: a steady overnight wave with nobody on the app is a machine, not a customer, and machines are the easiest reads to cut.

Treat the read meter as an operating surface, not a one-time audit. Each spike, each new feature, and each background job is a chance to confirm the cost is attributed before it compounds.

• Start at the largest bucket; that is where the cheapest win usually is.
• Watch for read patterns with no matching user activity.
• Re-check attribution whenever you add a feature or a scheduled job.

How should the whole team use it?

Read cost is not only an engineering concern. A founder watching runway wants the trend and the biggest line item. An engineer wants the exact path and environment to fix. Both are reading the same buckets, just at different depths.

When the cost is attributed by feature and labelled by environment, the conversation changes from “the database bill went up” to “this job, on the server, doubled — here is the fix.” That is the difference between a vague worry and a one-line task.

• Founder: watch the trend and the largest cost driver.
• Engineering: jump to the exact path and environment to fix.
• Everyone: reason from one attributed view instead of a single total.

Frequently asked questions