Supabase Free Tier Limits (2026): What You Get and How Pausing Works

Supabase's free tier is one of the most generous in the backend world. A full Postgres database, authentication for tens of thousands of users, file storage, edge functions, and realtime, all without adding a card. It's why so many side projects, MVPs, and early-stage startups start there. We run MyKavo on Supabase too.

But "free" comes with limits, and a few of them surprise people at exactly the wrong moment. The most famous is pausing: leave a free project quiet for a week, and Supabase pauses it. If that project powers a live app, your app stops working until someone notices and resumes it.

This guide lays out every free tier limit as of this month, what each one means in practice, how pausing actually works and how to handle it, and when it's worth moving to Pro.

Supabase free tier limits at a glance#

From Supabase's pricing page, checked this month:

Now let's go through what each one actually means.

Database size: 500 MB per project#

500 MB sounds small, but it's a lot of text data. A table of 100,000 users with names, emails, and a few settings takes a small fraction of that. Most side projects and early SaaS apps won't come near it for months.

What fills it up quickly: storing files or images directly in the database (use Storage instead), logging every event or page view into a table, large JSON blobs, and indexes on big tables, which take space too.

What to do: check your database size in the dashboard's usage page, keep files in Storage rather than table columns, and clean up or archive log-style tables regularly.

File storage: 1 GB#

Supabase Storage holds user uploads, images, documents, and other files. 1 GB fills faster than database storage if users upload photos or PDFs.

What to do: compress images before upload, set file size limits in your bucket settings, and delete orphaned files when records are removed.

Egress: 5 GB#

Egress is the data sent out from Supabase to your users: API responses, file downloads, and realtime messages. It's often the first limit a growing app runs into, especially if the app serves images from Storage or runs queries that return far more data than the page needs.

What to do: select only the columns you need instead of everything, paginate lists, serve images through a CDN or with appropriate caching, and avoid re-fetching the same data on every render.

Auth: 50,000 monthly active users#

This one is generous. 50,000 monthly active users is far beyond what most free-tier apps will reach. Pro raises it to 100,000, with a small per-user charge above that.

The auth-related limit people actually hit is email, not users. Supabase's built-in email service is meant for testing: it sends only 2 messages per hour and only to addresses of your project's team members. Real users signing up will see errors or never receive their confirmation email. For anything beyond testing, connect your own SMTP provider. Supabase's guide to sending emails with custom SMTP walks through it.

Edge Functions: 500,000 invocations#

Edge Functions run your server-side code. Half a million invocations a month is plenty for most early apps. Watch out for functions triggered by frequent events, like a function called on every page view or every database change, which can multiply quickly.

Realtime: 200 concurrent connections#

If your app uses Realtime subscriptions, each connected client counts. 200 simultaneous connections covers a small live dashboard or chat app, but not a popular one. If you only need data to refresh occasionally, polling every so often may be simpler than holding a realtime connection open.

Two active projects#

You can have two active free projects. Paused projects don't count toward the limit, which is one reason pausing exists: it frees up resources used by projects nobody's touching.

If you need more free projects, remember that the limit is on active ones, and a paused project can be resumed later.

No automatic backups#

This is the limit people tend to discover too late. Free projects don't get automatic daily backups, and there's no point-in-time recovery. If you drop a table by mistake, a migration goes wrong, or bad data overwrites good data, Supabase can't restore it for you on the free plan.

Supabase's own documentation recommends that free projects regularly export their data with the Supabase CLI's db dump command and keep backups somewhere else. Pro includes daily backups kept for 7 days. Supabase's backup and restore guide lists the exact CLI commands, and you can run them on a schedule.

Logs: kept for one day#

Free projects keep logs for one day. If something went wrong on Friday and you look on Monday, the evidence is gone. Pro keeps logs for 7 days.

What to do: if something breaks, look at the logs straight away. For anything important, send key events to your own logging or error-tracking tool.

How Supabase pausing works#

This is the limit that causes the most confusion, so here's exactly how it works, according to Supabase's documentation.

When a project pauses. A free project is considered inactive if it doesn't receive enough user database activity over the past week. Supabase's docs say that typically a few user requests to the database each day over the previous week is enough to keep a project active.

Warning emails. Supabase emails you roughly a week before pausing, and again once the project is paused. These often go to the inbox of whoever created the project, which isn't always the person maintaining the app.

What happens to your data. Nothing is lost when a project pauses. The database, auth users, storage, and settings all stay as they were.

What happens to your app. While paused, the project doesn't serve requests. Every API call, login, and data fetch fails. To your users, the app is broken.

How to restore. Open the Supabase dashboard, select the paused project, and click Resume project. It takes a few minutes to come back with everything intact. According to the docs, you can restore a paused project from the dashboard for up to a year after it was paused.

How to prevent it. Supabase's official answer is to upgrade to Pro, since paid projects are never paused. On the free plan, the project just needs real activity. A live app with daily users won't pause. The projects that pause are demos, portfolios, and apps with very little traffic.

Some developers set up a scheduled job that queries the database every few days to keep a low-traffic project awake. It works technically, but if the project matters enough to keep awake artificially, it usually matters enough for the Pro plan, which also brings backups and longer logs.

The real risk: finding out late#

Pausing itself isn't the problem. It's reasonable, it's documented, and your data is safe. The problem is how people find out.

The typical story goes like this: a small app, a client project, or an early product has quiet traffic for a week. The warning email goes to an inbox nobody checks. The project pauses. Then a customer, a recruiter looking at your portfolio, or a client's customer tries to use the app, and nothing works. You find out from them, maybe days later.

The same pattern applies to the other limits. Hitting your egress limit, running into realtime connection caps, or auth emails silently failing all look the same from the outside: the app is broken, and you're the last to know.

Free vs Pro, side by side#

The pattern is clear: Pro isn't mainly about more storage. It's about reliability and recovery, the things that matter once real people use your app.

How to check where you stand#

Before you hit a limit, it helps to know how close you are.

The usage page. In the Supabase dashboard, your organization's usage page shows database size, storage, egress, monthly active users, and function invocations for the current billing period, compared with your plan's limits.

Database size by table. If the database is growing faster than expected, run a size query in the SQL editor to see which tables and indexes take the most space. It's usually one log-style table.

Egress sources. If egress is climbing, look for queries that select all columns, lists without pagination, and large files served directly from Storage without caching.

Pause warnings. Pause warnings go to the project owner's email, so make sure that address is one someone actually reads.

A quick check once a month is enough for most free projects, and it turns surprises into planned decisions.

What counts as a monthly active user?#

Supabase counts a monthly active user as a distinct user who signs in or refreshes their session during the billing month. Users who exist in your auth table but don't use the app that month don't count. So 50,000 MAUs means 50,000 people actively using the app in a month, which is a large, real product, not a side project. If you're anywhere near that number, you almost certainly have revenue that justifies Pro anyway.

When to upgrade to Pro#

Pro starts at $25 a month and includes $10 of compute credits. Upgrade when any of these are true:

• Real users depend on the app. Pausing alone is reason enough to upgrade anything customers rely on.
• You need backups. Daily backups kept for 7 days, and point-in-time recovery is available as an add-on.
• You're approaching limits. Database size, storage, or egress creeping toward the caps.
• You need logs for more than a day to debug real issues.
• You need email support rather than community support.

For hobby projects, portfolios, and experiments, the free plan is excellent. Just plan for pausing and backups.

A free tier checklist#

1. Connect a custom SMTP provider before real users sign up.
2. Set up your own database backups with the Supabase CLI, on a schedule.
3. Keep files in Storage, not database columns, and compress images.
4. Select only the columns you need and paginate lists to save egress.
5. Check the usage page monthly.
6. Make sure pause-warning emails go to someone who'll act on them.
7. Set up monitoring on the app's key pages so a pause, a limit, or a broken login reaches you before it reaches users.
8. Upgrade to Pro once the app has users who depend on it.

Where MyKavo fits in#

MyKavo is our product, and we built it partly for exactly this situation. MyKavo watches the public pages of your app, like your homepage, pricing page, sign-up and login pages, and key content pages, and alerts you when something breaks or changes: an error status, content that disappeared, a missing form or button, or a changed title. Each alert includes the before and after, ranked by severity, sent to email, Slack, Discord, or a webhook.

So if a paused project or a limit starts breaking your pages, you hear about it from MyKavo rather than from a user. The free plan monitors one site and five pages on a weekly scan, and Pro ($20 a month) scans daily.

MyKavo also has a Supabase integration: on Pro and Agency plans, a Supabase Database Webhook or pg_net trigger can start a MyKavo check whenever your data changes, for example when a post is published. MyKavo never connects to your database, it only receives the webhook call.

What it won't do: MyKavo doesn't read your Supabase usage metrics, so it won't warn you that you're at 90% of your egress limit. Use Supabase's usage page and emails for that. MyKavo tells you when the result shows up on your live pages.

The bottom line#

Supabase's free tier gives you a real backend at no cost, and for side projects and early products it's hard to beat. The limits that matter most aren't storage or users. They're pausing, backups, and email, and each one is easy to handle once you know about it: resume or upgrade, back up with the CLI, connect your own SMTP.

The one thing to avoid is finding out from your users. MyKavo watches your app's key pages and alerts you, with evidence, when they break or change, and a Supabase webhook can start a check whenever your data changes. Start free.