SaaS on Free Tiers: An Architecture That Actually Holds
How to run a real SaaS on free tiers — Supabase, free AI APIs, free email — with the actual limits, what breaks first, the commercial-use rules people miss, and the design choices that keep it inside the budget.
A SaaS free tier architecture works when the database does most of the work (authorization, scheduling, reporting and background jobs inside Postgres), AI is optional and spread across several free providers, email is a graceful extra, and every limit is designed for rather than discovered. LetRelay runs this way on Supabase's free plan, free Gemini and Groq keys, and Resend's free email tier. The limits that actually bite are daily AI quotas, a paused project after a week of inactivity, and hosting terms that forbid commercial use.
The stack and its real limits
Numbers from each provider's own pricing or documentation pages:
| Service | Free allowance | What it's for in LetRelay |
|---|---|---|
| Supabase Free | 500 MB database, 1 GB file storage, 50,000 monthly active users, 5 GB egress, 200 concurrent Realtime connections, 2 million Realtime messages/month, 500,000 Edge Function invocations, 2 active projects; paused after 1 week of inactivity | Postgres, auth, RLS, Realtime, storage, cron |
| Groq Free | e.g. openai/gpt-oss-20b: 30 requests/min, 1,000/day, 8,000 tokens/min, 200,000 tokens/day |
Fast routing and answers |
| Gemini API free | Per-account limits shown in AI Studio; daily request quotas reset at midnight Pacific | Classification, embeddings, answers |
| Resend Free | 3,000 emails/month, 100/day, 3 domains | Invites, password resets |
Principle 1: make Postgres do the work
Every service you add has its own free-tier limit, credentials and failure mode. A database you already pay nothing for can do a surprising amount:
- Authorization with row-level security instead of an auth service — see the multi-tenant RLS guide.
- Scheduled jobs with
pg_croninstead of a job runner: purging old rows, retrying webhooks, sending scheduled blog pings. - Outbound HTTP with
pg_net: webhooks fire from database triggers without a queue service — see Slack and Discord webhooks. - Rate limiting with a table and a function instead of Redis — see rate limiting without Redis.
- Analytics with SQL functions instead of a BI tool — see an analytics dashboard with plain Postgres.
- Search with full-text search and
pgvectorinstead of a search service. - Plan limits with triggers — see enforcing a freemium plan gate in the database.
One platform, one set of limits to watch.
Principle 2: keep the database small
500 MB is a lot of text and very little media. LetRelay's entire blog — 34 posts with all their metadata — took under 0.5 MB. Requests, comments and tasks are similar: kilobytes each.
What fills a free database:
- Files stored as bytes in tables. Put attachments and images in object storage (1 GB on the free plan) and store only the path.
- Logs that never expire. Every log-like table needs a retention job. LetRelay purges rate-limit hits after a day, webhook logs and cached AI answers on schedules, and applies retention to chat on the free plan.
- Embeddings at full size. A 3,072-dimension float vector is about 12 KB; 768 dimensions is about 3 KB. Choose the smaller size unless you've measured a quality difference.
- Unused indexes. They cost space and write time; Supabase's database advisors flag them.
Principle 3: AI is optional and distributed
Free AI tiers are generous per call and strict per day. Design around it:
- Save first, enrich later. Nothing a user does waits on a model. See AI that degrades gracefully.
- Several providers, one gateway. When one model hits 429 or hangs, fail over to the next. See a free AI gateway with Gemini and Groq failover.
- Small prompts. At 8,000 tokens a minute, prompt size is capacity. LetRelay trimmed its how-to prompt from 2,200–2,600 tokens to about 1,900.
- Skip the model when rules suffice, and cache answers to repeated product questions.
- Meter per tenant so one customer can't spend everyone's quota.
Principle 4: the inactivity pause
Supabase pauses free projects after a week without activity. For a live product with users, that's rarely an issue; for a staging project or a quiet demo it is. Two consequences to design for:
- Scheduled jobs stop while paused. Anything that must happen on time (reminders, retries) will run late after a pause. Make jobs catch up: process everything overdue, not just "the last minute".
- External responses can expire.
pg_netkeeps HTTP responses for a limited time; a job that reconciles them must treat very old "sent" items as unknown and retry them.
Principle 5: read the hosting terms, not just the limits
This is the constraint people miss. Vercel's Hobby plan is free, and its documentation states that it restricts users to non-commercial, personal use only. That's fine for building and demos. A product that charges customers or shows ads needs a hosting plan or provider whose terms allow commercial use. Check before launch, not after the first invoice.
The same applies to AI and email providers: read each free tier's terms on commercial use and data handling before relying on it in production.
Principle 6: know what breaks first, and watch it
In rough order of when they bite for a small SaaS:
- Daily AI quotas — on a busy day. Mitigation: failover, caching, rules, meters.
- Email daily cap (100/day on Resend Free) — during a bulk invite. Mitigation: in-app notifications; stagger invites.
- Inactivity pause — on quiet projects. Mitigation: catch-up jobs.
- Realtime concurrent connections (200) — when many people keep the app open. Mitigation: subscribe only on screens that need live updates.
- Database size (500 MB) — later than you'd think if files live in storage and logs expire.
- Egress (5 GB) — images and file downloads. Mitigation: cache public assets.
Put the ones you can measure on an admin page, with a warning well before the limit.
When to start paying
Free tiers are a start, not a strategy. Upgrade when:
- A limit is hit by normal use, not abuse.
- You need guarantees free tiers don't give (no pausing, backups, support).
- Your hosting or provider terms require it (commercial use).
Because the architecture above keeps most work inside Postgres, upgrading is usually one plan change on one platform, not a migration.
FAQ
Can you run a real SaaS entirely on free tiers?
For an early product with modest usage, yes — if the design keeps most work in one database, treats AI and email as optional, and respects each provider's commercial-use terms. Plan the first paid upgrades before you need them.
What's the first free-tier limit a SaaS usually hits?
Often daily AI request or token quotas, then email sending caps. Database size tends to come later if files are kept in object storage.
Is Vercel's free plan allowed for commercial projects?
Vercel documents its Hobby plan as restricted to non-commercial, personal use. Commercial products need a different plan or host.
Why does my Supabase free project pause?
Supabase pauses free projects after a week of inactivity. Activity resumes it; design scheduled jobs to catch up afterwards.
Sources
Building Relay — the internal request desk with AI triage and SLA tracking.
Run your internal requests on LetRelay
AI triage, SLA-tracked queues, and bottleneck analytics — the help desk your team actually likes. Free to start.
Keep reading
Scheduled Jobs in Supabase with pg_cron: A Practical Guide
How to run scheduled jobs inside Postgres on Supabase with pg_cron — idempotent schedules in migrations, catch-up logic, locking down job functions, outbound HTTP with pg_net, monitoring runs, and the free-tier pause.
How to Reduce LLM Token Usage Without Worse Answers
Practical ways to cut LLM token usage — skip the model when rules suffice, send less context, route to smaller models, cache repeated answers, use provider prompt caching and cap output — with measured numbers from a production assistant.
Supabase Security Definer Functions: The Exposure You Might Miss
In Supabase, public-schema functions are callable over the API — and SECURITY DEFINER ones bypass row-level security. What our audit found in 117 such functions, the real damage paths, and the grants and rules that close them.