Supabase free tier limits, from signup to recovery

Supabase Free includes a 500 MB database, 1 GB of file storage, 50,000 monthly active users and separate 5 GB allowances for cached and uncached egress. That can cover a small app, but the signup email, a busy list page or an abandoned project can hit a different boundary first.

For an app with accounts, private event drafts and optional images, check the whole path: can someone sign up, can they load a reasonably sized page, and can you recover their records and files? The limits below were checked against Supabase’s documentation on 27 October 2026. The payload example was run locally; signup, quota enforcement and recovery were not tested on a hosted account.

What Supabase Free includes

The pricing page gives the headline allowances. The billing guide explains their scope: most usage is added across the organization, while database size also has per-project conditions.

Supabase advertises unlimited API requests on Free. The other meters still apply. An endpoint that repeatedly returns a large result can exhaust traffic without encountering a separate request-count ceiling.

For choosing between database providers, the maintained free-compute guide is the broader shortlist. Here the question is whether a Supabase prototype is ready for people to use.

Test signup outside your own team

The default Auth email service only sends to addresses belonging to your project’s team. It is currently limited to two messages an hour and is intended for exploration and testing. A successful confirmation email to your own address does not establish that a visitor can sign up.

If the app uses confirmation emails, password resets or magic links, configure a suitable custom SMTP service and test those flows with an address outside the team. That service has its own terms, limits and possible costs. Moving to a paid Supabase plan does not, by itself, turn the default sender into a production email service.

While testing access, follow Supabase’s Data API security setup. Browser clients use a publishable key with row-level security and appropriate grants. Database passwords, secret keys and service-role keys belong on the backend. For private event drafts, test an anonymous request and two different accounts: neither account should read the other’s records.

Make the list page small before estimating traffic

An event list needs titles and identifiers. It probably does not need every event description, every image and the rest of the user’s collection in its first response.

This Python example creates 200 synthetic records with 1,024-character notes, then serializes a 25-card page. It needs only the standard library:

import json

rows = [
    {"id": i, "title": f"Event {i:03}", "notes": "x" * 1024}
    for i in range(1, 201)
]
page = [{"id": r["id"], "title": r["title"]} for r in rows[:25]]

def size(value):
    return len(json.dumps(value, separators=(",", ":")).encode("utf-8"))

print(size(rows))  # 213093
print(size(page))  # 742

Python 3.14.6 printed those byte counts; no Supabase request was involved.

The example changes both the number of records and the fields returned because that is the list-page decision. In the real app, request a bounded page and explicit columns from the database. Downloading everything and trimming it in the browser would already have spent the outbound traffic.

Use the browser’s network tools to measure the real page, including images, Auth and repeated requests. This example measures an uncompressed JSON body; it excludes HTTP overhead, compression and hosted metering. Its byte counts are not a prediction of how many visits fit in 5 GB.

Supabase’s egress guide counts outgoing data from Database, Auth, Storage, Functions and Realtime. Cached egress applies to qualifying CDN cache hits; it is not a spare allowance you can assign to database results. Reducing responses lowers future traffic. It cannot erase traffic already counted during the billing cycle.

The 500 MB quota is not the physical disk

Supabase’s database-size guide separates three conditions:

• Database-size quota: the Free plan advertises 500 MB per project. Organization fair-use enforcement sums database sizes and uses their daily average over the billing period.
• Physical disk: a Free project has a fixed 2 GB disk, also used by PostgreSQL’s write-ahead log and other files. This is not an extra 2 GB data allowance.
• Read-only safeguard: at 95% disk usage, Supabase attempts to stop writes. A completely full disk can stop Postgres despite that safeguard.

An organization’s database-size fair-use restriction can produce HTTP 402 responses. Reducing today’s size may not clear it immediately because the period’s average remains elevated. Read-only SQL errors are a different condition. Check the dashboard’s restriction and disk information before deciding what to change.

Do not start deleting records because an API returns an error. Establish which limit is involved and preserve data you need before maintenance or migration.

Keep a recovery plan that includes the files

Free projects with insufficient database activity over a week can be paused. Supabase documents warnings and a dashboard Resume project action, with a one-year restoration window after pausing. If you return to an old demo, check its project state before debugging its frontend.

For something people depend on continuously, decide whether a pause requiring owner action is acceptable. Pro removes inactivity pausing; its subscription and project compute costs need a fresh budget. A plan upgrade applies to the whole organization, so budget for every project you keep there. Periodic artificial traffic is a poor substitute for making that availability decision.

Free does not include the paid plans’ automatic daily backups. Supabase recommends regular exports and off-site copies. A recovery plan for the event-photo app needs two parts:

1. Database: export the required schema and data, then rehearse restoring them into a disposable environment.
2. Uploaded objects: preserve the files separately, along with the identifiers or paths that reconnect them to the records. Database backups contain Storage metadata, not those file bytes.

A successful export is only half the check. Reopen the restored records and one uploaded image before relying on the process.

Before opening the app to users

Use a visitor outside your team to test signup and reset emails. Check anonymous and cross-account access. Measure the first list page, then repeat the test with enough event records to exercise pagination. Look at database size, disk and organization usage separately, and rehearse recovering both records and uploads.

If those checks expose a dependency you cannot support on Free, price that dependency before launch. It may be email, storage, recovery or availability rather than the database size you first looked at.