How a Single .select('*') in Supabase Turned Into 19 GB of Egress (and How to Fix It)

6 min read

The problem nobody sees coming

One morning I opened the Supabase dashboard for ReadyToRelease and found a usage spike that made no sense. The project had minimal traffic — a handful of users, mostly me testing features. But the egress graph looked like a mountain range. 19 GB out in a few days, from a single internal screen.

The culprit? One dashboard page doing .select('*') on a table that had grown much larger than I'd realized. No pagination, no column filtering, just give me everything on every page load. This post covers how to detect this pattern, why it's dangerous, and the exact fixes I applied to bring egress back to near zero.

---

What Supabase counts as egress

Egress (also called bandwidth) is any data that leaves Supabase toward your application — database query results, Storage file downloads, Edge Function responses, and even response headers all count. The free tier includes 5 GB of database egress per month; the Pro plan gives you 250 GB. Beyond that, you pay per GB.

The critical thing to understand is that egress is proportional to bytes returned, not to the number of queries. A single query that returns 2 MB of data generates 2 MB of egress every time it runs. If that query fires on every page load, the math compounds fast.

---

How .select('*') silently scales against you

When your table has 10 rows, .select('*') is harmless. When it has 50,000 rows with wide columns — JSON blobs, long text fields, timestamps, metadata — each query pulls everything. In my case the table stored market research data with large JSON payloads per row. I never noticed it growing because I was focused on features, not on byte counts.

// What I was doing — pulls every column, every row, on every load
const { data, error } = await supabase
  .from('research_results')
  .select('*')

This is not a Supabase bug. It's a database fundamentals issue: SELECT * is a development shortcut, not a production pattern. The difference is that with Supabase you feel it directly in the billing dashboard, not buried in a server log somewhere.

---

How to detect the source of the spike

Before fixing anything, find the source. Supabase gives you a few places to look:

1. Dashboard → Reports → Database — shows query volume and data transferred over time. Look for spikes that don't correlate with user traffic.
2. Dashboard → Logs → API — filter by table name or endpoint to find which routes are the busiest. Sort by response size.
3. pg_stat_statements — if you have access via the SQL editor, query it to see cumulative bytes scanned per query pattern.

In my case the spike was obvious: one route, consistent volume, happening every time the internal dashboard was opened — even by me during development. The traffic was nearly zero but egress was enormous.

---

The fix: four changes, near-zero egress

1. Select only the columns you need

This is the highest-impact change. Identify what the UI actually renders and request only those fields.

// Before
const { data } = await supabase
  .from('research_results')
  .select('*')

// After — only what the dashboard table displays
const { data } = await supabase
  .from('research_results')
  .select('id, title, status, created_at, score')

If a column holds a JSON blob or long text that isn't shown in the list view, don't fetch it. Load it on demand when the user opens the detail view.

2. Add real pagination

An unbounded query is a time bomb. As the table grows, so does every page load. Supabase's range() method maps directly to SQL LIMIT / OFFSET.

const PAGE_SIZE = 25

const { data, count } = await supabase
  .from('research_results')
  .select('id, title, status, created_at', { count: 'exact' })
  .order('created_at', { ascending: false })
  .range(page * PAGE_SIZE, (page + 1) * PAGE_SIZE - 1)

This caps your worst-case egress per request to PAGE_SIZE × average_row_size, regardless of how large the table gets.

3. Cache on the client

An internal dashboard doesn't need real-time data. If the data is valid for 60 seconds, don't re-fetch it on every navigation. In Next.js you can use fetch cache options, React Query's staleTime, or even a simple module-level variable for truly static reference data.

// React Query example — won't re-fetch for 60 seconds
const { data } = useQuery({
  queryKey: ['research_results', page],
  queryFn: () => fetchResults(page),
  staleTime: 60 * 1000,
})

4. Use .select() on inserts and updates too

This one is less obvious. When you do an upsert or update, Supabase returns the full modified row by default. If you only need the id back, say so:

// Returns only the id after insert — not the full row
const { data } = await supabase
  .from('research_results')
  .insert({ title, status })
  .select('id')

---

Results

After applying these four changes the egress for that dashboard dropped from ~19 GB over a few days to effectively zero — well under 1 MB per day with normal usage. The table has continued growing but the query cost stays flat because it's bounded by PAGE_SIZE and a fixed column list.

---

A note on monitoring going forward

Set up a usage alert in Supabase (Dashboard → Settings → Billing → Usage alerts) so you get notified before hitting plan limits, not after. Running .select('*') once during prototyping is fine. Shipping it to a route that runs on every load is where it becomes a real cost.

---

ReadyToRelease uses Supabase as its primary database for storing market research data. If you're building an indie SaaS and want to validate your idea before writing production-quality queries, check it out — market analysis for $3, no subscription.

---

The rule I apply now: never use .select('*') in production on any table that can grow. Always specify columns, always paginate, always ask "what's the worst-case byte count if this table has 100k rows?" before shipping a query.