SaaS on Free Tiers: An Architecture That Actually Holds

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_cron instead 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 pgvector instead 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_net keeps 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:

1. Daily AI quotas — on a busy day. Mitigation: failover, caching, rules, meters.
2. Email daily cap (100/day on Resend Free) — during a bulk invite. Mitigation: in-app notifications; stagger invites.
3. Inactivity pause — on quiet projects. Mitigation: catch-up jobs.
4. Realtime concurrent connections (200) — when many people keep the app open. Mitigation: subscribe only on screens that need live updates.
5. Database size (500 MB) — later than you'd think if files live in storage and logs expire.
6. 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

• Supabase — Pricing
• Supabase — pg_cron
• Supabase — pg_net
• Supabase — Database advisors
• Groq — Rate limits
• Google — Gemini API rate limits
• Resend — Pricing
• Vercel — Hobby plan