# Supabase Free Tier's 500MB Limit vs Self-Hosted Postgres Costs

Claire Dawson · August 28, 2026

> Supabase Free Tier's 500MB Limit vs Self-Hosted Postgres Costs. The widely circulated advice to simply self-host PostgreSQL ignores t...

| Takeaway | Detail |
| --- | --- |
| Managed backend services eliminate hidden operational overhead that erodes theoretical savings. | Supabase's free tier bundles authentication, object storage, and realtime subscriptions while handling backup scheduling and connection pooling, removing the need for manual infrastructure maintenance. |
| Self-hosted database deployments require paid compute resources that quickly surpass managed entry-level pricing. | A dedicated Hetzner CX22 VPS runs approximately $6 per month, while AWS EC2 m5.large instances cost roughly $70 monthly for compute alone, excluding storage and networking fees. |
| Connection management architecture dictates whether a self-hosted stack can handle production traffic efficiently. | Traditional Postgres caps connections at 100 to 400 depending on memory, making tools like Supavisor or PgBouncer essential for scaling client requests without exhausting server resources. |
| Entry-level managed plans offer predictable pricing that scales cleanly beyond initial free allowances. | Supabase transitions from its zero-cost tier to a Pro plan at $25 monthly and a Team plan at $99 monthly, providing fixed-price bundles that simplify budget forecasting. |

The widely circulated advice to simply self-host PostgreSQL ignores the actual financial reality of running a production database. While the open-source software itself carries no licensing fees, the underlying infrastructure required to keep it secure and available demands consistent capital expenditure. A single Hetzner CX22 virtual private server costs approximately $6 monthly, and larger AWS EC2 configurations easily exceed $70 in compute charges alone. These baseline hardware expenses immediately negate the theoretical zero-dollar advantage when compared against managed alternatives.

Beyond raw server costs, the operational burden fundamentally shifts the total cost of ownership. Maintaining a standalone instance requires dedicating two to four hours each month to automated backups, security patching, and connection-pool configuration. When these maintenance windows are valued against standard engineering opportunity costs, the effective price difference between managed platforms and DIY deployments widens dramatically. Small datasets rarely justify the administrative overhead required to sustain a custom stack.

Supabase addresses this friction by bundling critical backend components directly into its architecture. The platform includes built-in authentication, edge functions, and real-time subscriptions alongside a managed Postgres layer that handles routine maintenance automatically. For applications staying within the 500MB storage threshold, the monthly bill remains exactly $0. This structural approach proves that managed infrastructure often delivers superior economic efficiency for early-stage projects compared to unmanaged hosting solutions.

![Supabase Free Tier's 500MB Limit vs](https://static.mm-ais.com/article-images-ai/supabase-free-tier-s-500mb-limit-vs-self-ai-cb0a5460.jpg)

## The 500MB Ceiling

Supabase's free tier enforces a hard ceiling on total database size measured via `pg_database_size`, not a row count. As of 2026, the quota stack includes 500MB database storage, 5GB monthly egress, 50,000 monthly active users, and support for two concurrent free projects. The critical constraint is the 7-day inactivity auto-pause: a project with zero API requests for seven calendar days enters a paused state requiring manual restoration. Restored instances retain all persisted data but immediately lose real-time availability, a mechanism that effectively invalidates the free tier for low-traffic side projects or background workers that do not generate constant request volume.

The persistent myth that Supabase caps you at a few thousand rows ignores the arithmetic of schema density. At a typical 1KB row—such as a JSONB event record with twelve columns—the 500MB limit accommodates approximately 500,000 rows. However, if your schema compresses to 200-byte rows, like a slim feature vector table, the same 500MB holds roughly 2.5 million rows. You must compute your own bytes-per-row ratio; the cap is fundamentally a function of your serialization strategy, not an arbitrary row limit.

Your raw data rarely consumes the full 500MB allowance. System schemas for PostgREST and GoTrue occupy baseline space, while indexes impose significant overhead. According to standard B-tree mechanics, an index on a UUID primary key adds roughly 20 to 40 bytes per row. Large JSONB payloads trigger TOAST compression, which can mitigate bloat but introduces CPU costs during writes. Furthermore, UPDATE-heavy workloads generate dead tuples that consume space until `VACUUM` reclaims them; without aggressive maintenance, your effective capacity shrinks rapidly.

| Factor | Impact on 500MB Cap | Mitigation Strategy |
| --- | --- | --- |
| PostgREST/GoTrue Schemas | Fixed baseline consumption | Acceptable overhead; negligible for most schemas |
| B-tree Index (UUID PK) | +20 to 40 bytes per row | Monitor index growth; drop unused secondary indexes |
| TOAST Compression | Reduces JSONB payload size | Use for large blobs; accept write-CPU tradeoff |
| Dead Tuples | Consumes space until reclaimed | Schedule regular VACUUM operations |
| 7-Day Inactivity Pause | Kills real-time availability | Implement heartbeat pings or self-host if idle |

Self-hosted PostgreSQL 16 removes the storage ceiling entirely, replacing it with your disk provisioner. Software licensing remains free, but you assume operational responsibility for `pg_dump` scheduling, version upgrades, and connection security from day one. A 4.51/month Hetzner CX22 instance ships with 40GB of storage, providing approximately 80 times the free-tier capacity. This architecture allows direct configuration file access for custom performance tuning, bypassing platform abstractions. When your projected row growth threatens to breach 400MB within twelve months, or when your application cannot tolerate the latency of pausing and restoring, migrating to a self-hosted VPS becomes the cost-effective decision.

![The 500MB Ceiling — Supabase Free Tier's 500MB Limit vs](https://static.mm-ais.com/article-images-ai/supabase-free-tier-s-500mb-limit-vs-self-ai-67abd714.jpg)

## What the Numbers Say: $0 vs 4.51 vs $25

At a glance, the cost differential appears binary: Supabase Free sits at $0 while self-hosted infrastructure demands cash outlay. However, this surface comparison ignores the operational tax that defines the true break-even point. According to Supabase's published pricing page, the Free tier provides 500MB of database storage with no monthly fee. The Pro tier jumps to $25/month for an 8GB database and removes the auto-pause risk. For self-hosting, Hetzner lists the CX22 instance at 4.51/month on its 2026 pricing page, while DigitalOcean prices the Basic Droplet at $6/month per its 2026 pricing pages. The raw math suggests self-hosting is cheaper than the Pro tier, but it remains more expensive than the Free tier unless you treat your labor as having zero value.

The hidden line items in self-hosting quickly erode the apparent savings. Automated backup retention requires external object storage; according to standard S3-standard pricing models, retaining 30 days of pg_dump snapshots typically costs between $1 and $2 per month depending on growth velocity. If you opt for a managed middle path like Neon or Crunchy Bridge to offload the ops burden, costs rise to $19–$39/month, narrowing the gap with Supabase Pro significantly. More critically, self-hosted Postgres runbooks document approximately 2–4 hours of monthly operations time required for security patching, restore-testing, and log rotation. At even a modest valuation of $15/hour, this adds $30–$60 in implicit cost, making the ~$6 VPS effectively more expensive than the $25 Pro tier for any project requiring reliability. Self-hosting only beats the Free tier in pure dollars when your ops time is valued at $0/hour, since 4.51 exceeds $0.

| Option | Monthly Cost | Key Constraint | Winner Condition |
| --- | --- | --- | --- |
| Supabase Free | $0 | 500MB cap, 7-day pause | Best for 8GB needed |
| Supabase Pro | $25.00 | 8GB cap, no pause | Best for 400MB–8GB, high uptime need |

Egress economics further skew the decision matrix. Supabase's Free tier includes 5GB of monthly egress; exceeding this triggers overage charges that force an upgrade to the paid tier. In contrast, Hetzner includes 20TB of traffic on the CX22, representing a 4,000x difference in bandwidth allowance. This disparity matters only if your application serves data-heavy API responses to a large client base. For most lead-scoring or outreach tools where payloads are text-light, the egress ceiling rarely bites before the storage limit does.

To anchor these figures in reality, consider a verifiable benchmark: a one-million-row table containing 400-byte lead-event records with two indexes measures approximately 610MB in Postgres when accounting for data, index bloat, and fillfactor overhead. This dataset busts the Supabase Free tier's 500MB cap immediately, forcing either schema optimization or a migration. However, it fits comfortably within the disk allocation of a $6 VPS and sits well below the Pro tier's 8GB limit. This confirms the canonical rule: stay on the Free tier until your measured database size approaches 400MB (80% of the cap) or your project cannot tolerate the seven-day inactivity pause. Only then should you migrate to a self-hosted VPS or the Pro tier, as the fixed costs of hosting and operations become justified by the scale of your data.

![What the Numbers Say: alt=](https://static.mm-ais.com/article-images-pixabay/supabase-free-tier-s-500mb-limit-vs-self-f11308b6.jpg)

## The Decision Table

The decision matrix below resolves the cost-versus-control trade-off by scoring five deployment topologies across operational dimensions. The comparison isolates the variables that actually determine total cost of ownership: cash outlay, storage limits, availability guarantees, backup reliability, and the developer hours required to maintain the stack.

| Topology | Monthly Cost | Row/Size Ceiling | Auto-Pause Risk | Backup Automation | Ops Hours/Mo | Winner For |
| --- | --- | --- | --- | --- | --- | --- |
| Supabase Free | $0 | ~500K rows (500MB) | High (7-day inactivity) | Managed daily snapshots | 0–1 | 100K–500K rows; $0 budget |
| Supabase Pro ($25/mo) | $25 | 8GB database | None (SLA-backed) | Managed PITR + snapshots | 0 | Production apps requiring uptime |
| Hetzner CX22 (~€4.51/mo) | ~$6 | 40GB disk (expandable) | Low (single point of failure) | Manual or external cron scripts | 2–4 | 500K–5M rows; ops-capable teams |
| Neon Free Tier | $0 | 3GB database | High (auto-pause on idle) | Automated branch snapshots | 0–1 | Serverless edge functions; low volume |
| Local Postgres | $0 | Host hardware limit | None (always running) | None (local only) | 0 | Development; prototyping |

For the 100K to 500K row regime, Supabase Free is the unambiguous winner on total cost of ownership. The math is structural: $0 monthly spend beats 4.51 plus 2 to 4 hours of maintenance time, even when valued at a conservative $15/hour. At this scale, the managed REST API and automated backups eliminate the engineering labor that makes self-hosting expensive in practice. You pay for infrastructure you do not need while gaining a production-grade endpoint without writing boilerplate.

When projected growth crosses 500K rows toward 5M, the economics invert. Self-hosted Postgres on a Hetzner CX22 wins over Supabase Pro because $25/month buys 8GB of database storage you likely do not require. A 40GB VPS disk costs a fraction of the managed tier's price, providing ample headroom for mid-sized schemas. This victory holds provided you accept the operational burden: patching, monitoring, and configuring your own backup cadence. According to Portable, self-hosted PostgreSQL software carries no licensing fees, making the marginal cost purely hardware-based.

In scenarios where downtime is unacceptable, Supabase Pro wins decisively. The free tier's 7-day auto-pause mechanism and absence of an SLA render it unusable for any service a customer depends on. While self-hosting a single VPS offers lower latency than cloud regions, it introduces a single point of failure with worse uptime characteristics than a managed platform featuring automated failover. Fly.io's Managed Postgres pricing data indicates that managed high-availability configurations typically exceed $38/month before add-ons, yet the reliability premium justifies the cost for revenue-critical applications.

Migration cost serves as the critical tie-breaker. Moving off Supabase requires rewriting PostgREST-dependent API calls and re-implementing Row Level Security policies, effectively locking in roughly one developer-week of effort for a mid-sized schema. Conversely, migrating between standard Postgres instances relies on `pg_dump` and restore workflows, which are reversible and low-friction. You should weight Supabase lock-in at approximately one developer-week when evaluating long-term flexibility. If your roadmap demands eventual migration away from vendor-specific extensions, the extra $6 per month for self-hosting may be the insurance premium worth paying today.

![The Decision Table — Supabase Free Tier's 500MB Limit vs](https://static.mm-ais.com/article-images-pixabay/supabase-free-tier-s-500mb-limit-vs-self-52c11fbe.jpg)

## What the Data Doesn't Tell You

Row-size variance is the silent killer of the 500K-row heuristic. The canonical rule assumes a uniform ~1KB row footprint, but real-world lead-event data rarely behaves so politely. JSONB payloads in production ingestion pipelines routinely span from 150 bytes for simple status flags to 15KB when capturing full browser fingerprints and interaction histories. This tenfold variance means your table can hit the 500MB storage ceiling at roughly 50,000 rows instead of 500,000. Relying on average row size is a calculation error; you must execute `pg_total_relation_size` against your actual schema to measure the true disk consumption, including indexes and TOAST bloat, rather than trusting theoretical density.

The cost calculus shifts dramatically for operators who already maintain idle infrastructure. My baseline thesis assumes a marginal ops cost of $15/hour, translating to 2–4 hours of maintenance per month for patching, backups, and version upgrades. However, developers running home servers or maintaining idle VPS instances for unrelated projects face near-zero marginal costs for additional database workloads. For these practitioners, self-hosting is genuinely free, as the fixed hardware cost is sunk. The decision rule here requires honest accounting: if your existing compute stack has spare capacity and you are not billing your own time, the break-even point for self-hosting vanishes entirely.

Any dollar comparison carries a finite shelf life due to policy volatility in Supabase's 2026 terms. Free-tier quotas and inactivity-pause windows have shifted historically; notably, the project limit dropped from three to two, and pause thresholds have moved without extensive notice. Because the pricing page is subject to revision, a current cost advantage may evaporate before your schema stabilizes. You should treat the free tier as a provisional state and re-verify the current limits on the pricing page before committing a complex schema that might trigger unexpected egress or storage penalties.

Egress volume often imposes a harder constraint than row count. A lead-scoring application performing a single large `SELECT` to pull full feature tables into a Python training loop can consume 5GB of bandwidth instantly. On the free tier, this triggers immediate throttling or overage risks, whereas self-hosted environments typically offer generous allowances. According to Hetzner, standard bare-metal and cloud instances include 20TB of traffic per month, effectively eliminating egress as a failure mode. If your workload involves bulk data extraction for model training or heavy API fan-out, the 5GB monthly cap becomes the binding constraint, not the database size.

Pricing tables omit the performance tax of shared compute. Free-tier projects receive no uptime SLA and sit lower in the priority queue for CPU cycles. Under identical load, p95 query latency on the free tier can degrade by several multiples compared to an isolated VPS. This variance is critical for user-facing applications where sub-second response times define retention. If your product cannot tolerate latency spikes during resource contention, the operational savings of the free tier are negated by the risk of poor user experience.

| Deployment Mode | Marginal Ops Cost | Egress Allowance | Winner Condition |
| --- | --- | --- | --- |
| Supabase Free Tier | $0 cash / $15+ hourly value | 5GB/month hard cap | Low egress, new ops team,

Canonical: https://mm-ais.com/blog/supabase-free-tiers-500mb-limit-vs-self-hosted-postgres-costs.php
Markdown: https://mm-ais.com/blog/supabase-free-tiers-500mb-limit-vs-self-hosted-postgres-costs.php/index.md