Free-tier limits that are real
What actually constrains a free deployment: pausing databases, capped realtime connections, image optimisation quotas and request body size.
A deployment on free tiers works. These are the edges, stated plainly rather than discovered.
| Limit | Effect | Mitigation |
|---|---|---|
| A Supabase project pauses after seven days of inactivity | The site returns database errors until it is resumed | A daily keep-alive cron |
| Realtime concurrent connections are capped | The live stream degrades under many simultaneous editors | Automatic fallback to polling |
| Image optimisation is capped per month | Transforms stop being generated | Aggressive caching, then serving originals |
| Serverless request bodies cap at about 4.5 MB | Large uploads fail on the server-receive path | Browser-direct upload |
| Function execution has a time limit | Long-lived streams cannot run indefinitely | Keepalives, a clean close and client reconnection |
| Hobby plans forbid commercial use | Not a technical limit, but a real one | A paid plan |
The one that surprises people
The pausing database. A demo deployment nobody visits for a week comes back to errors that look like a broken build. The keep-alive cron exists precisely because "it worked when I deployed it" and "it works today" are different claims for an unvisited project.
Scaling past them
Nothing here is architectural. The database is a Postgres, the storage is object storage, and both scale by paying for them. The only code-level limits are the ones marked partial on the compatibility page.