DEV Community: Victor Caña

How I turned a single Supabase query into 19GB of egress

Victor Caña — Tue, 14 Apr 2026 16:12:48 +0000

The problem

I caught it in Supabase billing metrics: one dashboard query was responsible for a massive jump in egress, way out of proportion to the actual traffic.

At first, it looked like a normal internal dashboard issue. In reality, a single .select('*') on a large table was quietly pulling far more data than the UI ever needed.

Technical context

The app is ReadyToRelease, built with Next.js 14 and Supabase, and this query lived inside an internal dashboard. It was not a Stripe bug, not a Groq issue, and not a frontend rendering problem. The real issue was simpler and more dangerous: the dashboard was asking Supabase for every column in every matching row.

That kind of query is easy to miss during development because it works fine on small datasets. But once the table grows and the dashboard starts loading often, the cost profile changes fast. In my case, the result was 19GB of egress before I noticed what was happening.

The problematic code

Here was the original query:

const { data } = await supabase
  .from('reports')
  .select('*')
  .eq('user_id', userId)

This looks harmless at first glance. The problem is that * is a convenience shortcut, not a performance strategy. It returns every column, including fields the dashboard never displayed, which increases payload size and therefore egress.

The second issue was that the query did not limit the number of rows. Even if each row is moderate in size, a few hundred or a few thousand rows can become expensive when the query runs often.

The fix

The solution was to make the query explicit and bounded:

const { data } = await supabase
  .from('reports')
  .select('id, created_at, status, title')
  .eq('user_id', userId)
  .range(0, 24)

This changed two things:

It fetched only the columns the dashboard actually rendered.
It limited the result set to 25 rows.

That reduced payload size immediately, which brought egress down to almost nothing and made the dashboard feel faster at the same time.

Why this worked

The lesson is that egress problems are often query design problems in disguise. When you fetch more fields than you render, you pay for data transfer you do not use. When you fetch more rows than the interface needs, you multiply that waste across every load.

In this case, the fix was not a bigger cache, a new edge layer, or a database rewrite. It was simply making the query match the UI.

General rule

If a screen only shows five fields and 25 rows, the query should probably ask for five fields and 25 rows.

That rule sounds obvious, but it is easy to ignore when you are moving quickly. Defaults like .select('*') are convenient during prototyping, yet they can become expensive once real users and real tables enter the picture.

One useful habit is to treat every dashboard query like a public API response: return only what the client needs, nothing more. That keeps payloads smaller, latency lower, and billing surprises less likely.

Closing note

A single query can be cheap in development and expensive in production. In my case, that difference showed up as 19GB of Supabase egress and a very avoidable bill.

The fix was small, but the lesson was not: data transfer costs are often hidden in plain sight, inside code that “works” but returns far too much.

Related reading: you can find more details about Supabase cost traps (including how .maybeSingle() can silently fail when multiple rows exist) in my post Supabase: When .maybeSingle() silently fails with multiple rows.

Next.js 14 www non-www redirects: GSC errors that won't die (and how I fixed them)

Victor Caña — Tue, 07 Apr 2026 12:55:22 +0000

Next.js 14 www → non-www redirects: GSC errors that won't die (and how I fixed them)

Switched from www.readytorelease.online → readytorelease.online.

Vercel 308 redirects = perfect.

Google Search Console: 4 “Crawled - currently not indexed” errors on WWW after 72h.

Here’s the fix that took me 3 days to figure out.

The problem

When you run:

curl -I https://www.readytorelease.online

You get:

HTTP/2 308
location: https://readytorelease.online/

Looks fine, right?

Permanent redirect in place, only one GSC property (readytorelease.online), and correct redirect logic in next.config.js.

But GSC still showed 4 “Crawled - currently not indexed” errors for www.readytorelease.online URLs.

Brand new ones (March 21–23).

Deleting the old property or hitting Validate Fix did nothing for days.

Root cause

Google caches WWW versions even after you stop serving them or delete the old property.

Those cached responses can persist 24–72 hours, confusing GSC into thinking redirects are broken.

The 3 fixes that actually worked

1. next.config.js redirect (already done, but critical)

// next.config.js
async redirects() {
  return [
    {
      source: '/:path*',
      has: [{ type: 'header', key: 'host', value: 'www.readytorelease.online' }],
      destination: 'https://readytorelease.online/:path*',
      permanent: true, // 301
    },
  ]
}

This catches any request hitting the www. host and permanently redirects it to the root domain.

2. Google Search Console → Coverage cleanup

Go to Index → Pages → “Excluded”.

Filter all URLs containing "www.".

Click “Validate Fix” on all of them.

This tells Google to recrawl those URLs — usually within 24 hours — and refresh their redirect cache.

3. Aggressive URL Inspection

From GSC:

Inspect https://www.readytorelease.online
Hit “Test live URL” → confirm that 308 redirect responds correctly
Then “Request indexing”

Even though it sounds redundant, this step forced Google to acknowledge the redirect and finally cleared the WWW errors.

Result (after 24 h)

✅ GSC shows “Validated” for all previous WWW URLs

✅ Coverage report is clean

✅ +15% impressions on non-www URLs

✅ No more "Crawled - not indexed" ghosts

The key lesson

GSC caches redirects for 24–72 hours, even if your site returns perfect 301 or 308 responses.

If curl -I or fetch() show correct status codes, don’t panic over small (<10) errors.

But if they persist, use the Validate Fix + Test live URL combo to force Google’s refresh.

Conclusion

Vercel’s redirects are instant.

GSC’s understanding of them isn’t.

Sometimes the crawler is the real bottleneck.

Repo: readytorelease.online (Next.js 14 + Vercel)

Twitter: @shipwithvictor

🔍 Curious how I used AI to validate my market before launch?

Check out readytorelease.online — built with Next.js 14, Groq, and Supabase to automate market research for indie products.

Next.js Server Component fetch cache: no-store: the performance trap

Victor Caña — Tue, 17 Mar 2026 16:19:56 +0000

You added cache: 'no-store' to a fetch call inside a Server Component because you needed fresh data. Reasonable. Standard. The docs even show it. What they don't tell you is that in the wrong place, that single option can turn one page load into hundreds of server invocations.

The context

Server Components in Next.js 14 look deceptively simple. They run on the server, they fetch data, they render HTML. No client bundle, no useEffect, no loading states. Clean.

But Server Components aren't rendered once and cached like a static page. Depending on where they sit in your component tree and how your routes are configured, they can re-execute on every request, or worse, on every rerender triggered by a parent.

Add cache: 'no-store' to a fetch inside one of these components, and you've just told Next.js: skip every layer of caching, always go to the origin, on every single execution.

The problematic code

This is the pattern that causes the issue:

// app/dashboard/page.tsx: a dynamic route
async function getMarketData(query: string) {
  const res = await fetch(`https://your-api.com/analyze?q=${query}`, {
    cache: 'no-store', // 👈 "I need fresh data"
  })
  return res.json()
}

export default async function DashboardPage({ searchParams }) {
  const data = await getMarketData(searchParams.query)
  return <ResultsView data={data} />
}

Looks fine. But now imagine this page is wrapped in a layout that re-renders on navigation, or the component is used inside a Suspense boundary that retries on error, or you're running in a deployment where Vercel's infrastructure invokes the function per request segment.

Each execution → one fetch call → one external API hit. At scale, or with any retry/rerender loop, this compounds fast.

In my case with ReadyToRelease, a single user session generated 776,000 Vercel function invocations in under 24 hours. The root cause was exactly this pattern, cache: 'no-store' inside a Server Component on a dynamic route with no deduplication in place.

Why `cache: 'no-store'` is dangerous here

Next.js has its own fetch deduplication layer. When you call the same URL multiple times during a single render pass, Next.js deduplicates those requests automatically, but only when using the default cache behavior or cache: 'force-cache'.

The moment you use cache: 'no-store', you opt out of that deduplication. Every call is treated as unique. Every render = a real network request.

// This is deduplicated across the render tree ✅
const res = await fetch('https://api.example.com/data')

// This is NOT deduplicated: each call hits the network ❌
const res = await fetch('https://api.example.com/data', {
  cache: 'no-store'
})

If your component tree renders the same Server Component multiple times (parallel routes, multiple Suspense boundaries, layout + page both fetching), you're making multiple real requests.

What to use instead

Option 1: next: { revalidate: N }: time-based freshness

const res = await fetch('https://your-api.com/analyze', {
  next: { revalidate: 60 } // Fresh every 60 seconds, cached in between
})

You get reasonably fresh data without hammering the origin on every render. Good for data that changes, but not by the millisecond.

Option 2: Route Segment Config: control at the route level

// app/dashboard/page.tsx
export const dynamic = 'force-dynamic' // entire route opts out of static
export const fetchCache = 'default-no-store' // fetch behavior for this segment

// Then your fetch stays clean:
const res = await fetch('https://your-api.com/analyze')

This separates the concern. The route is dynamic, but fetch deduplication still applies within a single render pass.

Option 3: Move the fetch outside the component tree

// lib/market-data.ts
import { cache } from 'react'

export const getMarketData = cache(async (query: string) => {
  const res = await fetch(`https://your-api.com/analyze?q=${query}`)
  return res.json()
})

React's cache() function memoizes the result per request. Call it from ten different components in the same render, it executes once. This is the correct primitive for deduplication in Server Components.

The general rule

cache: 'no-store' doesn't mean "always fresh per user session." It means "always fresh per execution." In a Server Component, those are not the same thing.

Use cache: 'no-store' only when you understand exactly how many times that component will execute per request,
and that number is one. Otherwise, use revalidate, route-level config, or React.cache().

Conclusion

The fetch API in Next.js Server Components looks like the standard browser fetch. It isn't. The caching layer underneath has different semantics, and cache: 'no-store' removes a safety net you probably didn't know was there. Learn where your deduplication comes from before you opt out of it.

Supabase .maybeSingle() returns null with multiple rows, and it won't tell you why

Victor Caña — Tue, 10 Mar 2026 14:31:09 +0000

The problem

You query Supabase with .maybeSingle(), get null back, and assume the row doesn't exist. It does. There are actually three of them. Your app just silently moved on.

Technical context

When building ReadyToRelease, I had a query that checked whether a user already had an active research session before creating a new one. Classic "upsert-like" logic: if it exists, return it; if not, create it.

I trusted .maybeSingle() to handle the "maybe it's there, maybe it's not" case cleanly. It does, but only if your data is clean. The moment you have duplicate rows matching your filter, .maybeSingle() doesn't throw. It doesn't warn. It returns null, exactly like it would if nothing matched.

This is documented behavior. But it's the kind of thing you only truly understand after it burns you in production.

The broken code

const { data, error } = await supabase
  .from('research_sessions')
  .select('*')
  .eq('user_id', userId)
  .eq('status', 'active')
  .maybeSingle()

if (!data) {
  // Assumes: no active session exists → create one
  await createNewSession(userId)
}

This looks reasonable. But if the user somehow ended up with two active rows (a race condition, a bad migration, a test script you forgot to clean up), data comes back as null, and you create another session on top of the existing duplicates.

No error. No warning. Just null and a silent cascade.

What's actually happening under the hood

.maybeSingle() is designed to return:

The row, if exactly one matches
null, if zero match
null + an error, if more than one match but only in some versions and configurations

The catch: in Supabase JS v2, the behavior when multiple rows match changed subtly. Instead of always surfacing a PGRST116 error, under certain query patterns it silently collapses to null. If you're not explicitly checking error and validating that null actually means "not found", you're flying blind.

The fix

Two layers of defense:

1. Always check the error, even when data is null:

const { data, error } = await supabase
  .from('research_sessions')
  .select('*')
  .eq('user_id', userId)
  .eq('status', 'active')
  .maybeSingle()

if (error) {
  // Could be PGRST116, multiple rows found
  console.error('Unexpected query result:', error.message)
  throw new Error('Ambiguous session state, manual review needed')
}

if (!data) {
  await createNewSession(userId)
}

2. If you need true single-row safety, use a count check first:

const { count, error: countError } = await supabase
  .from('research_sessions')
  .select('*', { count: 'exact', head: true })
  .eq('user_id', userId)
  .eq('status', 'active')

if (countError || count !== 1) {
  throw new Error(`Expected 1 active session, found ${count}`)
}

const { data } = await supabase
  .from('research_sessions')
  .select('*')
  .eq('user_id', userId)
  .eq('status', 'active')
  .single() // safe now

Yes, it's two queries. For critical paths, it's worth it.

The general rule

null from .maybeSingle() means "zero or ambiguous", not "definitely zero".

Treat it like you'd treat an HTTP 200 with an empty body: don't assume it means what you think it means without checking everything around it. Always inspect error. Always add a database-level unique constraint if business logic requires exactly one row per user/status combination.

-- The real fix lives here
CREATE UNIQUE INDEX one_active_session_per_user
ON research_sessions (user_id)
WHERE status = 'active';
![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cypnd64lif2ughooz9zf.png)

That index makes the problem impossible at the data layer, which is where it belongs.

Conclusion

.maybeSingle() is not broken, your assumption about what null means is. Add the constraint, check the error, and never let your application logic be the only thing enforcing uniqueness.

Supabase .maybeSingle() returns null with multiple rows, and it won't tell you why

Victor Caña — Tue, 10 Mar 2026 14:31:09 +0000

The problem

You query Supabase with .maybeSingle(), get null back, and assume the row doesn't exist. It does. There are actually three of them. Your app just silently moved on.

Technical context

This is documented behavior. But it's the kind of thing you only truly understand after it burns you in production.

The broken code

const { data, error } = await supabase
  .from('research_sessions')
  .select('*')
  .eq('user_id', userId)
  .eq('status', 'active')
  .maybeSingle()

if (!data) {
  // Assumes: no active session exists → create one
  await createNewSession(userId)
}

No error. No warning. Just null and a silent cascade.

What's actually happening under the hood

.maybeSingle() is designed to return:

The row, if exactly one matches
null, if zero match
null + an error, if more than one match but only in some versions and configurations

The fix

Two layers of defense:

1. Always check the error, even when data is null:

const { data, error } = await supabase
  .from('research_sessions')
  .select('*')
  .eq('user_id', userId)
  .eq('status', 'active')
  .maybeSingle()

if (error) {
  // Could be PGRST116, multiple rows found
  console.error('Unexpected query result:', error.message)
  throw new Error('Ambiguous session state, manual review needed')
}

if (!data) {
  await createNewSession(userId)
}

2. If you need true single-row safety, use a count check first:

const { count, error: countError } = await supabase
  .from('research_sessions')
  .select('*', { count: 'exact', head: true })
  .eq('user_id', userId)
  .eq('status', 'active')

if (countError || count !== 1) {
  throw new Error(`Expected 1 active session, found ${count}`)
}

const { data } = await supabase
  .from('research_sessions')
  .select('*')
  .eq('user_id', userId)
  .eq('status', 'active')
  .single() // safe now

Yes, it's two queries. For critical paths, it's worth it.

The general rule

null from .maybeSingle() means "zero or ambiguous", not "definitely zero".

-- The real fix lives here
CREATE UNIQUE INDEX one_active_session_per_user
ON research_sessions (user_id)
WHERE status = 'active';
![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cypnd64lif2ughooz9zf.png)

That index makes the problem impossible at the data layer, which is where it belongs.

Conclusion

.maybeSingle() is not broken, your assumption about what null means is. Add the constraint, check the error, and never let your application logic be the only thing enforcing uniqueness.

I broke my SaaS with one line of code -> 776,000 function invocations and account paused

Victor Caña — Wed, 04 Mar 2026 19:16:30 +0000

Three months ago, ReadyToRelease had its peak user count.
Then I broke everything with one line of code.

Here's the full story.

What is ReadyToRelease

An AI tool that generates market research reports in 90 seconds:
TAM/SAM/SOM, competitor analysis, SWOT, and implementation roadmap.
One-time $3 payment. No subscription.

Stack: Next.js 14 + Groq + Supabase + Stripe

The bug that caused 776,000 function invocations

In my reports page, I had this:

const res = await fetch(
  `${process.env.NEXT_PUBLIC_BASE_URL}/api/generate-report?id=${params.id}`, 
  { cache: 'no-store' }
);

This fetch was inside a Next.js Server Component with
cache: 'no-store'.

Every time someone visited a report page, this triggered:

A full call to /api/generate-report
Which launched 9 parallel scrapers inside Promise.allSettled()
Which called Supabase, GitHub API, Reddit API, and 5 VC firm scrapers
Every. Single. Visit.

Result: 776,000 Vercel function invocations in 3 weeks.
Vercel account paused. Product completely down.

The fix was removing 9 lines of code. The report data was already
being read directly from Supabase above: the fetch was completely
unnecessary.

The Supabase egress problem

At the same time, I had this in my dashboard:

const { data: reportsData } = await supabase
  .from("reports")
  .select(`
    id, title, market_data, competitors, 
    trends, swot_analysis, financial_projections
  `)

I was loading full JSONB fields (150KB+ each) for a list view
that only needed id, title, and created_at.

20 reports × 150KB = 3MB per dashboard visit.
Result: 19GB of Supabase egress on the free tier in 3 weeks.
Account restricted. 402 errors everywhere.

Fix: select only the fields you actually need.

const { data: reportsData } = await supabase
  .from("reports")
  .select("id, title, created_at, status, business_model")

The webhook that didn't exist

I built the entire Stripe payment flow but the webhook endpoint
file was in the wrong path.

My code pointed to: /api/stripe/webhook
My file was at: /api/stripe-webhook/route.ts

Every payment succeeded on Stripe.
Nothing was recorded in the database.
Users paid and got nothing.

Fix: stripe listen --forward-to localhost:3000/api/stripe-webhook

The .maybeSingle() that wasn't

After migrating to a new Supabase project, users who had
multiple rows in report_payments were getting blocked.

The query:

const { data: payment } = await supabaseAdmin
  .from("report_payments")
  .select("id")
  .eq("user_id", user.id)
  .maybeSingle() // fails silently with multiple rows

When maybeSingle() finds multiple rows it returns null.
So !payment was true and the endpoint returned 402.

Fix:

const { data: payments } = await supabaseAdmin
  .from("report_payments")
  .select("id")
  .eq("user_id", user.id)
  .limit(1)

if (!payments || payments.length === 0) {
  return NextResponse.json({ error: "Payment required" }, 
  { status: 402 })
}

What I rebuilt in 3 months of silence

Migrated to a new Supabase project (old one hit egress limits)
Fixed all payment verification bugs
Removed ReactFlow from bundle (it was imported but never used — dead code adding ~150kB)
Added dynamic imports for heavy components
Added rate limiting (max 3 reports/hour per user)
Added skeleton loaders on dashboard
Added /api/health endpoint + UptimeRobot monitoring

The unit economics

AI cost per report: $0.0125 (Groq, 11 LLM calls)
Price: $3
Margin: 240x
Infrastructure cost: $0/month (free tiers)

Where I am now

Product is back live: readytorelease.online
Demo (no signup needed): readytorelease.online/demo
0 paying customers. Relaunching today.

If you're building with Next.js + Supabase, the main lessons:

Never use cache: 'no-store' in Server Components without understanding what it triggers
Always select specific fields, never .select("*") on heavy tables
Test your webhook path before going live
.maybeSingle() returns null for multiple rows — use .limit(1) instead

Happy to answer questions about the stack or any of the bugs.

DEV Community: Victor Caña

How I turned a single Supabase query into 19GB of egress

The problem

Technical context

The problematic code

The fix

Why this worked

General rule

Closing note

Next.js 14 www non-www redirects: GSC errors that won't die (and how I fixed them)

Next.js 14 www → non-www redirects: GSC errors that won't die (and how I fixed them)

The problem

Root cause

The 3 fixes that actually worked

1. next.config.js redirect (already done, but critical)

2. Google Search Console → Coverage cleanup

3. Aggressive URL Inspection

Result (after 24 h)

The key lesson

Conclusion

Next.js Server Component fetch cache: no-store: the performance trap

The context

The problematic code

Why cache: 'no-store' is dangerous here

What to use instead

The general rule

Conclusion

Supabase .maybeSingle() returns null with multiple rows, and it won't tell you why

The problem

Technical context

The broken code

What's actually happening under the hood

The fix

The general rule

Conclusion

Supabase .maybeSingle() returns null with multiple rows, and it won't tell you why

The problem

Technical context

The broken code

What's actually happening under the hood

The fix

The general rule

Conclusion

I broke my SaaS with one line of code -> 776,000 function invocations and account paused

What is ReadyToRelease

The bug that caused 776,000 function invocations

The Supabase egress problem

The webhook that didn't exist

The .maybeSingle() that wasn't

What I rebuilt in 3 months of silence

The unit economics

Where I am now

Result (after 24 h)

Why `cache: 'no-store'` is dangerous here