Supabase Free Tier Limits Hit: Migration Strategy Options

The moment your app logs start throwing row limit exceeded errors in production is a bad morning. Worse when the migration strategy you needed was never planned—because you assumed you’d deal with it later.

Later is now.

Supabase’s free tier has become the default starting point for indie hackers, side projects, and early-stage startups. It’s genuinely generous. But those limits are hard ceilings, not soft warnings. In 2026, with more production apps bootstrapping on Supabase than ever before, hitting those ceilings mid-launch is a real operational risk—not a theoretical one.

This breaks down exactly where the limits sit, what breaks first, and how to execute a clean migration before—or after—things go sideways.

In brief: Supabase’s free tier caps at 50,000 database rows and 1GB of file storage—both of which production apps regularly exceed within weeks of launch. Upgrading to Pro ($25/month) resolves most constraints, but the migration itself requires deliberate planning to avoid downtime.

1. The free tier’s row limit applies per project, not per table—a subtle distinction that catches developers off guard.
2. Storage limits and bandwidth caps (2GB egress/month on free) often trigger before the row limit in media-heavy apps.
3. Migration isn’t just a billing change—it requires auditing your schema, storage buckets, and edge function usage simultaneously.

The Limits Are Specific. Know Them Cold.

Supabase’s free tier in 2026 caps at:

• 50,000 rows across your entire database (not per table)
• 1GB file storage in Supabase Storage
• 2GB egress bandwidth per month
• 500MB database size (separate from row count)
• 2 projects per account
• Edge Functions: 500,000 invocations/month

According to Supabase’s official documentation and the breakdown published by UI Bakery, the row limit is the one developers underestimate most. A typical SaaS app with users, sessions, audit logs, and notification records can burn through 50,000 rows in three to four weeks of active usage. That’s not a scaling failure—that’s normal growth.

The storage limit hits differently. If you’re handling user avatars, document uploads, or any media pipeline, 1GB disappears fast. A product with 500 users uploading profile photos and one document each could hit the storage cap within the first month, according to the Metacto pricing breakdown of Supabase’s tier structure.

The egress cap is the sneaky one. Every image served from Supabase Storage counts against the 2GB monthly limit. A modest e-commerce app serving product images to 300 daily visitors can exhaust that bandwidth in under two weeks.

What Actually Breaks First

Not all limits trigger the same failure mode. Understanding the cascade matters when you’re triaging a production incident.

Database rows hit a hard stop. New INSERT operations fail with a quota error. Existing reads still work. Your app doesn’t go dark—but any write path (signups, order creation, form submissions) stops cold.

Storage limits behave similarly. Uploads fail; existing files remain accessible. So a user can view their old documents but can’t upload new ones. That’s a confusing UX failure that’s hard to diagnose without checking your Supabase dashboard first.

Egress bandwidth throttles rather than hard-stops in some configurations, but effectively your Storage CDN slows to unusable speeds. Image-heavy pages break visually. API responses with attached assets time out.

The order of failure for most apps: egress bandwidth → storage uploads → row inserts. Media-light, data-heavy apps flip that order.

Migration Options: A Direct Comparison

When you’ve hit—or you’re approaching—the decision point, three paths exist.

The Pro upgrade is the obvious move for most teams. The billing change is instant, limits expand immediately, and your connection strings don’t change. No migration in the traditional sense—it’s a plan change, not a platform change.

Self-hosting Supabase via Docker (officially supported in 2026 via supabase/supabase on GitHub) makes sense only if you’re dealing with data residency requirements or genuinely high scale where Pro’s add-on costs—$0.125/GB storage overage, $0.09/GB egress overage per Supabase’s pricing docs—start compounding.

The “optimize and stay free” path works, but it’s borrowed time. Offloading storage to Cloudflare R2 (free egress, $0.015/GB storage) handles the file problem cleanly. Archiving or soft-deleting old rows buys database headroom. But you’re engineering around a constraint rather than removing it—and that engineering time usually costs more than $25/month.

This approach can also fail in ways that aren’t obvious upfront. Teams that invest heavily in free-tier optimization sometimes discover that the refactoring required—custom archival logic, external storage integrations, row pruning jobs—introduces new failure points that a simple Pro upgrade would have avoided entirely.

Executing the Migration Without Downtime

If upgrading to Pro: The migration is mostly procedural.

1. Go to your Supabase project dashboard → Settings → Billing → Upgrade
2. Verify the new limits are reflected (they apply within minutes)
3. Audit your storage buckets—Pro includes 100GB, but check your bucket policies haven’t been overly restrictive
4. Review Edge Function invocation counts if you’re near the 500K free limit (Pro bumps this to 2M/month)
5. Set up billing alerts at 70% of new thresholds—don’t wait for the ceiling again

If migrating storage to an external provider: Cloudflare R2 is the current default recommendation for teams wanting to reduce Supabase egress costs. The process:

• Create an R2 bucket, generate API keys
• Update your app’s storage client to point at R2 (S3-compatible API)
• Run a one-time script to copy existing Supabase Storage files to R2
• Update any signed URL generation logic in your backend
• Keep old Supabase Storage files accessible during transition—don’t delete until URLs expire

If self-hosting: Expect 4–8 hours of setup time minimum, plus ongoing maintenance overhead. The official Supabase self-hosting guide covers Docker Compose deployment. Test in staging first. Production DNS and SSL configuration are the most common failure points—not the database setup itself.

This isn’t always the answer. Self-hosting trades a predictable $25/month bill for unpredictable ops time. For most teams at early scale, that’s a bad trade.

What the Next Six Months Look Like

A few things worth tracking:

Supabase’s pricing trajectory. The company raised a $200M Series C in late 2024, according to Crunchbase. Free tier limits have held steady through 2025–2026, but that’s not guaranteed indefinitely as infrastructure costs scale with the user base.

R2 + Supabase hybrid stacks are becoming the standard architecture for cost-aware teams. Expect more official tooling or integrations in this space.

Row-level limits may shift. Supabase has discussed moving to storage-size-based limits rather than row-count limits in community threads. That would benefit apps with many small rows but hurt those with fewer, larger ones. Worth monitoring if your schema skews either direction.

The migration decision shouldn’t be reactive. Set dashboard alerts. Know your growth rate. Run the math on when you’ll hit each ceiling. At a typical SaaS growth rate of 15–20% week-over-week in early traction, a 50,000-row ceiling can arrive faster than any sprint cycle can respond to.

The free tier is a launch pad, not a permanent home. Most apps outgrow it within 60–90 days of real traction. The Pro upgrade at $25/month is almost always the right call—cheap relative to the engineering time spent optimizing around limits. Self-hosting earns its complexity only at genuine scale or under compliance constraints.

Plan the transition before you’re forced into it at 2 AM.

What’s your current Supabase row count? Check the dashboard now—not when signups start failing.

References

1. Supabase Pricing in 2026: Plans, Free Tier Limits & Full Breakdown | UI Bakery Blog
2. Supabase Pricing 2026 [Complete Breakdown]: Free Tier Limits, Pro Costs & Hidden Fees
3. Limits | Supabase Docs

Photo by NASA on Unsplash