Supabase Free Tier Limits in 2026: What You Actually Get (And When You Will Hit Them)#

The Supabase free tier is one of the best deals in developer infrastructure. But there are specific limits that will catch you off guard if you do not know about them. I have hit most of them while building side projects, and I want to save you the same surprises.

Here is every limit that matters, in order of how likely you are to hit it.

The Limits That Actually Matter#

1. Project Pausing (The One That Hurts Most)#

Limit: Projects with no activity for 7 days are automatically paused.

This is the limit that trips up the most people. You build an MVP, share it with some friends, then go on vacation. You come back and your app is dead — with a "Project paused" message.

Resuming is easy (click a button in the dashboard, wait ~30 seconds), but if your app is live and a user tries to use it during that window, they get errors.

When you will hit it: On any project you are not actively developing or receiving traffic to.

How to avoid it (free tier): Set up a lightweight ping that runs every 3-4 days. Add this to your GitHub Actions:

# .github/workflows/keep-alive.yml
name: Keep Supabase Alive

on:
  schedule:
    - cron: "0 8 */3 * *"   # every 3 days at 8am UTC

jobs:
  ping:
    runs-on: ubuntu-latest
    steps:
      - name: Ping Supabase
        run: |
          curl -s "${{ secrets.NEXT_PUBLIC_SUPABASE_URL }}/rest/v1/" \
            -H "apikey: ${{ secrets.NEXT_PUBLIC_SUPABASE_ANON_KEY }}" \
            -o /dev/null

Add NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY as repository secrets and this runs silently every 3 days.

The real fix: Upgrade to Pro. No pausing, ever.

---

2. Database Storage: 500MB#

Limit: 500MB of PostgreSQL storage (data + indexes + system tables).

How much is 500MB really?

It depends on your data shape. Here are rough estimates:

| Use case | Approximate row count | |----------|----------------------| | Simple user profiles | ~2 million rows | | Blog posts with content | ~50,000 posts | | Chat messages (short) | ~5 million messages | | Logs / analytics events | ~500,000 events |

Images and files do NOT count against database storage — those go to Supabase Storage (covered below). Only structured data in PostgreSQL tables counts.

Check your current usage:

SELECT
  pg_size_pretty(pg_database_size(current_database())) AS total_size;

Or in the dashboard: Settings → Usage → Database Size.

When you will hit it: If you are storing large text content (blog posts, documents), logging user events, or building a chat app. Not a concern for most early-stage apps.

How to delay it:

• Do not store file contents in database columns — use Supabase Storage
• Archive old data to a separate table and truncate periodically
• Use VACUUM to reclaim space after bulk deletes

-- Check which tables are using the most space
SELECT
  schemaname,
  tablename,
  pg_size_pretty(pg_total_relation_size(schemaname || '.' || tablename)) AS size
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY pg_total_relation_size(schemaname || '.' || tablename) DESC;

---

3. Bandwidth: 5GB per month#

Limit: 5GB of data transferred out per month across the REST API, Realtime, Storage, and Edge Functions.

When you will hit it: Rarely on the free tier unless you are serving large files through Supabase Storage. API responses for typical app data are small (JSON). 5GB is roughly:

• 50 million requests returning 100 bytes each
• 500,000 requests returning 10KB each
• Serving 5,000 images averaging 1MB each

If you are serving images or files, use Supabase Storage's CDN integration rather than the direct storage URL — CDN-served assets do not count against your bandwidth quota.

---

4. Auth: 50,000 Monthly Active Users#

Limit: 50,000 MAUs (users who sign in at least once per month).

This is extremely generous for a free tier. 50,000 MAUs is a real product with real users. Most projects never hit this.

An MAU is counted only when a user logs in. Users who exist in auth.users but do not log in that month do not count. Tokens refreshed silently in the background do count as activity.

When you will hit it: When you have a successful app, which is a good problem to have.

One thing to watch: if you are building a B2B app with large enterprise clients who have many employees, you can hit MAU limits faster than you expect even with few paying customers.

---

5. Storage: 1GB#

Limit: 1GB of file storage (images, videos, documents, etc.).

1GB sounds small but goes further than you think:

• ~500 compressed images at 2MB each
• ~200 PDF documents at 5MB each
• ~10,000 thumbnails at 100KB each

When you will hit it: If users upload content (avatars, attachments) or if you store generated assets.

Best practice: Set image size limits in your app before upload, and use transformation parameters to serve resized versions:

const { data } = supabase.storage
  .from('avatars')
  .getPublicUrl(`${userId}/avatar.jpg`, {
    transform: {
      width: 200,
      height: 200,
      resize: 'cover',
    },
  });

Transformed images are cached by Supabase's CDN and served from there. The original stored file is the source of truth; transformations are free.

---

6. Edge Functions: 500,000 Invocations#

Limit: 500,000 Edge Function invocations per month.

Each call to a Supabase Edge Function counts as one invocation. Unless you are calling Edge Functions on every page load for a high-traffic app, this is not a concern on the free tier.

When you will hit it: Building webhooks, background jobs, or server-side processing that runs very frequently.

---

7. No Backups (The Silent Risk)#

This is not advertised prominently enough.

Free tier projects have no automatic backups. If you accidentally delete your data, run a bad migration, or your project encounters corruption, there is no safety net. You cannot restore to a previous state.

Pro plan includes daily backups with 7-day retention. You can restore to any point within the last 7 days.

If you have any users depending on your app, the $25/month Pro plan is worth it for backups alone.

DIY backup on free tier: You can dump your database manually via the Supabase CLI:

supabase db dump --db-url postgresql://postgres:[password]@db.[ref].supabase.co:5432/postgres > backup.sql

Set this up as a weekly GitHub Action that commits the dump to a private repository. Not as good as proper backups, but better than nothing.

---

Free vs Pro: Is It Worth $25/Month?#

| Feature | Free | Pro ($25/mo) | |---------|------|--------------| | Database storage | 500MB | 8GB | | Bandwidth | 5GB | 250GB | | Auth MAUs | 50,000 | 100,000 | | File storage | 1GB | 100GB | | Edge Functions | 500K invocations | 2M invocations | | Project pausing | After 7 days inactive | Never | | Daily backups | None | 7 days | | Support | Community | Email | | Concurrent connections (pgBouncer) | Shared | Dedicated |

Upgrade to Pro when:

• You have paying customers (never pause = no downtime = worth it)
• You are storing user-uploaded content that will grow
• Your database is approaching 400MB (you want headroom before it becomes urgent)
• You want backups (always)

Stay on free when:

• You are actively building and testing
• You have no users depending on uptime
• Your project is a weekend experiment

The free tier is genuinely designed to get you to a real product. Supabase is not trying to trick you into upgrading — the limits are reasonable for pre-traction projects.

---

One More Thing: The 2 Free Projects Limit#

You can have a maximum of 2 active free projects per organization. If you want a third, you either have to delete one or upgrade an organization to Pro.

This catches indie hackers who build multiple MVPs simultaneously. Plan your projects accordingly — or create separate Supabase organizations (each gets 2 free projects) if you have genuinely separate projects that will not share infrastructure.