Short answer: no. Long answer: it’s a great prototyping tier and a terrible production tier, and the line between them is exactly the moment you have a paying customer. Here’s what every limit actually means.
The Supabase free tier gives you a 500 MB Postgres database, 5 GB of monthly egress, 50,000 monthly active users on auth, 500K edge function invocations, and 1 GB of file storage — for $0/month, as long as your project keeps getting traffic. That last clause is the trap. A free Supabase project that sees zero requests for seven days gets paused. Not throttled. Paused. The site returns errors until you log in and click resume. For anything you’d call a SaaS — even a single-customer SaaS — that alone disqualifies Free.
Limits verified against supabase.com/pricing as of May 2026. Community reports drawn from public Reddit threads (r/Supabase, r/SaaS, r/indiehackers) and GitHub discussions. We have not personally hit every limit listed; this is a research synthesis, not a single founder’s tour.
Yes for prototyping. No for paying customers. The 7-day-pause-on-inactivity trap, the 500 MB database cap, and the lack of point-in-time recovery make the free tier unsafe for any product where users would notice an outage. Stop using it the moment you have a paying customer — even one.
Pro at $25/month removes the auto-pause, raises database to 8 GB, bandwidth to 250 GB, MAU to 100,000, and adds daily backups with 7-day retention. That $25 is the cheapest insurance you will ever buy against a Monday-morning outage.
Pull these numbers from supabase.com/pricing if you want to double-check. They shift a few times a year, usually upward. The reality-check column is what actually matters once you’re shipping code.
| Resource | Free | Pro | Reality check |
|---|---|---|---|
| Monthly cost | $0 | $25 + usage | The $25 buys you a real product, not bigger numbers. |
| Database size cap | 500 MB | 8 GB included, then $0.125/GB-month | Events tables and audit logs blow past 500 MB fast. |
| File / object storage | 1 GB | 100 GB included, then $0.021/GB-month | Any product with user uploads exceeds 1 GB within weeks. |
| Egress / bandwidth per month | 5 GB | 250 GB included, then $0.09/GB | 5 GB = roughly 1,000 MAU on a normal API + small images. |
| Cached egress per month | 5 GB | 250 GB included, then $0.03/GB | CDN cache hits count too. Not unlimited. |
| Monthly active users (auth) | 50,000 | 100,000 included, then $0.00325/MAU | Free trial users count. Anyone who logs in counts. |
| Edge function invocations | 500,000 / month | 2,000,000 included, then $2/million | Adequate for most apps until heavy webhook or AI proxy traffic. |
| Realtime concurrent connections | 200 | 500 included, then $10/1,000 | 200 is fine for collaborative apps under ~500 MAU. |
| Realtime messages / month | 2 million | 5 million included, then $2.50/million | Generous unless you have a chat product. |
| Daily backups | None | Daily, 7-day retention | If you drop a table, you lose everything since your last manual dump. |
| Point-in-time recovery (PITR) | Not available | Add-on: $100/month for 7-day retention | PITR is what lets you restore to a specific minute. Pro doesn’t include it by default. |
| Auto-pause after inactivity | Paused after 7 days of zero requests | Never pauses | The single biggest reason to leave Free. Cron-pinging is a hack, not a fix. |
| Vector embeddings (pgvector) | Available, counts against 500 MB DB | Available, counts against 8 GB DB | 10K 1536-dim OpenAI embeddings = ~60 MB just for vectors. Math fast. |
| Number of active projects | 2 | Unlimited | Staging environment eats your second slot. |
| Compute / RAM | Shared CPU, 500 MB RAM | 2-core ARM, 1 GB RAM (Micro instance) | Free runs on shared compute. Cold queries are noticeably slower. |
| Direct DB connections | ~60 max | Higher; scales with compute add-on | Pooler gives ~200, but long-lived connections still exhaust the pool. |
| Support tier | Community only (Discord, GitHub) | Email support, no SLA | If your DB is down on Free, your only recourse is forum threads. |
The six numbers worth memorizing before any architectural decision: 500 MB database, 5 GB egress, 50K MAU, 1 GB file storage, 2 active projects, 7-day pause clock. Everything else is a downstream consequence of one of those.
Generic warnings are useless. Here are the six specific ways a real founder ends up regretting they stayed on Free past launch day. Every one of these has shown up repeatedly in r/Supabase and r/indiehackers threads since at least 2023, and the underlying limits have not changed enough to retire the complaints.
This is the single most-discussed Supabase pain point in public communities. The rule: if your Free project receives no API requests for 7 consecutive days, Supabase pauses the project. The database is preserved, but the URL returns errors and your app is effectively offline until you log into the dashboard and click resume. That click takes 1–2 minutes to bring the project back up.
In practice, this kills seasonal B2B tools (tax software, quarterly reporting) that go quiet mid-quarter, and anyone whose launch is a Show HN post that catches fire on Reddit two weeks later — by which point the database has paused and the URL returns errors exactly when traffic finally arrives. The community workaround is a cron job pinging the REST API weekly to keep the project warm. It works mechanically. It is not a serious solution for a product with paying customers, because if the cron breaks (GitHub Actions outage, expired token), you find out via support ticket from your customer.
This one is worse than the docs make it sound. Free tier gets no automatic backups at all. Pro gets daily backups with 7-day retention. Point-in-time recovery — the ability to restore your database to a specific minute, which is the only kind of backup that actually saves you from a botched migration — is a $100/month add-on even on Pro.
Concrete scenario: you’re running a migration at 2am, you fat-finger a DROP TABLE users on production instead of staging, and you have no PITR. On Free, you have lost every user record since whenever you last ran pg_dump manually. On Pro without the PITR add-on, you can restore to a backup taken some time in the last 24 hours but every signup since then is gone. Only the $100/month PITR add-on lets you rewind to 1:59am specifically.
For a hobby project this is annoying. For a product with even ten paying customers, this is a refund-and-apologize incident. Our how much SaaS costs to build guide walks the rest of the reliability-tax line items.
A Postgres row with a UUID primary key, two timestamps, and four normal columns is roughly 300–500 bytes including index overhead — so roughly 1 million rows fits in 500 MB on a single table. Events tables, audit logs, and webhook receivers blow through that in weeks. An analytics events table at 100 pageviews per user per day, across 200 users, generates 600,000 rows per month, well over 500 MB once payload columns are counted. AI applications logging every prompt and completion hit the cap at ~25,000 chat sessions (20 turns averaging 1 KB each).
Worse: pgvector embeddings count against the same 500 MB. A standard OpenAI embedding (1536 dimensions, float4) takes ~6 KB per row. Ten thousand documents indexed for semantic search is 60 MB of vectors alone — before any HNSW index overhead, which doubles or triples it. See true cost of running an AI SaaS for the full embedding-cost picture.
5 GB of monthly egress is either a workable cap or a brick wall depending on what your app serves. A pure-API SaaS at 5 KB per JSON response and 100 requests per user per month uses 500 KB per MAU — 5 GB serves about 10,000 MAU comfortably. A mobile or web app delivering cached images is different. Each thumbnail at 50 KB, each full image at 300 KB, a user browsing 20 thumbs and 5 full images per session twice a month uses ~4.5 MB per MAU. 5 GB at 4.5 MB per MAU is about 1,100 MAU. Not enough headroom for any real consumer SaaS. Cached egress (CDN cache hits) counts against a separate 5 GB cap, not unlimited.
Supabase’s built-in email provider on Free tier is rate-limited and aggressively throttled. The exact published rate has shifted (Supabase has tightened these limits at least twice to combat abuse), but it’s in the range of a few emails per hour, not the volume needed for any real signup flow. If you’re sending magic-link emails via the default provider on Free and you have any meaningful signup velocity, users complain that the email never arrived. It did — it was rate-limited.
The fix is plumbing your own SMTP (Resend, Postmark, AWS SES) through the Supabase auth settings, which works on Free but requires actually doing it. Most founders only discover this exists when the first batch of users from a launch complains.
You get 2 active projects on Free. If you want a proper staging environment, that’s slot 2. Now you have zero room for a separate analytics project, a marketing-site database, or a second product. Most solo founders run a staging Supabase by mid-development; once you do, your project budget is exhausted.
You can keep extra projects in a paused state on Free, but that means they’re not running — useless for active development. This is one of the most common “wait, I have to upgrade to do that?” moments founders hit. It’s also the most defensible upsell in Supabase’s entire pricing structure.
The free tier exists for real reasons, and dismissing it wholesale would be dishonest. Here are five workloads where Free is genuinely the right answer, with the numbers behind each.
If you’re still wiring up your schema, building auth flows, and testing your business logic, the free tier is exactly what you want. 500 MB is enough for any reasonable seed dataset. 50K MAU is enough for any beta cohort. The auto-pause doesn’t matter because you’re hitting the database every day yourself. Use Free until you have a working product or a paying customer, whichever comes first.
A genuinely small side project with under 100 monthly users, daily activity from at least one user, and minimal user-generated content fits comfortably inside every Free tier limit. The math: 100 MAU at 30 page views each at 5 KB per response is 15 MB of egress per month — 0.3% of your cap. The 500 MB database holds about 1M small rows, plenty of headroom. The auto-pause never triggers because you have daily activity.
Internal CRUD apps used by 5–20 people inside a single company virtually never exceed any Free tier limit. The only risk is the weekend pause, which a single GitHub Actions cron job hitting /rest/v1/ daily prevents reliably enough for non-customer-facing tooling.
Disposable demo environments, conference-talk apps, hackathon projects, and tutorials are exactly what the free tier was designed for. Spin it up, run the demo, delete it next month. Same applies to learning Postgres, Row Level Security, edge functions, or pgvector — nothing you build while learning needs the Pro features. Our guide on setting up Supabase RLS for multi-tenant SaaS assumes you’re testing on Free first.
Pro is $25/month flat plus usage-based overages. The base $25 gets you 8 GB database (16x Free), 250 GB egress (50x), 100 GB file storage (100x), 100K MAU (2x), 2M edge function invocations (4x), daily backups with 7-day retention, no auto-pause, and unlimited projects.
What to budget for on top of $25, in order of likelihood:
Full breakdown including overage math at 10K and 50K MAU lives in Supabase pricing explained; the wider stack math is in SaaS cost at 1K MRR.
Pro at $25/month is the obvious default. It is not the only option, and a few alternatives are genuinely better for specific shapes of product.
Neon is the closest direct competitor on serverless Postgres. The free tier gives 0.5 GB per project with up to 10 projects (aggregate 5 GB), and the paid Launch plan offers storage at $0.30/GB-month for the first 50 GB — cheaper per-GB than Supabase Pro’s $0.125 on first inspection looks worse, but Neon’s no-flat-fee approach means small workloads can be cheaper overall. Neon also has branch-pause-resume that’s analogous to Supabase’s auto-pause but designed for ephemeral environments, not a punishment for low traffic. See Supabase vs Neon for the head-to-head.
Vercel Postgres (powered by Neon under the hood for most accounts) is worth considering if you’re already deep in the Vercel ecosystem. Pricing is similar to Neon. The reason to pick it is co-location with your Next.js compute.
Self-hosted Supabase on Hetzner is a real option for cost-sensitive founders. A CX22 instance runs about €4.50/month and can host the full Supabase stack via Docker Compose. The catch: you own the backups, the patches, and the 3am pages. For most solo founders this is false economy.
Firebase is the most-mentioned alternative for product founders who don’t care about Postgres specifically. The free Spark tier is more generous on some axes (no auto-pause, 1 GB Firestore, 10 GB bandwidth) and tighter on others (no relational model, vendor lock-in). See Supabase vs Firebase and best Supabase alternatives for the full list.
A SaaS at 1K MRR with ~50 paying customers and ~500 free-tier users typically uses 2–5 GB of database, 30–80 GB of egress, and 1–3 GB of file storage. The bill on each option:
For most solo founders at 1K MRR, Pro is the right answer. The PITR add-on is worth it once you cross ~$5K MRR or 100 paying customers, whichever comes first.
The recurring complaints about Supabase Free in public threads have stayed remarkably consistent for two-plus years. Four themes show up over and over:
Pause shock. The most-upvoted complaints in r/Supabase are variations on “woke up to find my database paused, lost a launch.” The 7-day clock is documented but easy to miss when you’re focused on building. The frustration is not the rule itself — it’s that the pause is silent (no email warning at day 6) and the recovery requires a manual dashboard click rather than auto-resume on first request. Multiple community guides exist purely to automate the “ping every six days” cron pattern, which itself indicates how widespread the problem is.
Migration friction once you outgrow Free. Moving from Free to Pro is one click. Moving from Supabase entirely is harder — the Postgres dump is easy, but rebuilding auth, RLS policies, and edge functions on a new platform is real work. This is true of Firebase too, just on different axes.
Connection pool exhaustion on Free. Free ships with ~60 max direct connections and ~200 pooler connections. Fine for serverless functions that grab a connection briefly. Painful for long-lived connections from a persistent server, or any framework that holds connections open per-request. “Sorry, too many clients already” errors are usually traceable to using the direct connection string instead of the pooler URL.
Auth email deliverability. The built-in email sender is rate-limited tightly on Free. “Half my signups never got the magic link” threads from launch weeks trace back to this. The fix — plumbing in your own SMTP via Resend or Postmark — is in the docs but not the default. Anyone running a real launch on Free without configuring custom SMTP first is going to have a bad signup day.
None of these are deal-breaking flaws. They are the trade-offs you take in exchange for $0/month. Which is exactly why Free exists for prototyping, not production.
You haven’t taken money yet. Auto-pause hurts your weekend project, not a customer relationship. The 500 MB cap is plenty for testing real schemas. Stay on Free until you have either a paying customer or you’re about to publicly launch.
One paying customer means one person who notices when your project pauses on a quiet Tuesday. $25/month is materially less than the cost of a refund-plus-apology incident. Upgrade the same day you turn on Stripe.
Even at $3 ACV, the customer expects the product to work. Free-tier auto-pause and no backups are not appropriate for any paid B2B context. The $25/month is ~8 customer-months at $3/customer. Eat the math.
If your product delivers a lot of media, Supabase’s $0.09/GB egress will dominate your bill. Cloudflare R2 has zero egress fees. The right architecture is Neon (or any Postgres) for relational data plus R2 for media storage and delivery. Supabase Pro’s integrated storage is convenient but not cost-optimal at scale.
Supabase Free is genuinely good. A real Postgres database with auth, storage, edge functions, and realtime — for $0/month, indefinitely — is a remarkable bundle. Use it. Build on it. Prototype your whole product on it.
Then upgrade to Pro the day you take a paying customer, or the day before you publicly launch, whichever comes first. The $25/month is not a tax on success. It is the difference between “real product” and “hobby project that occasionally serves real customers.” Pay it. Or move to Neon, or self-hosted, or Firebase. Just don’t run a real SaaS on a tier that gets paused after a quiet week.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.