Ask HN: Hit Supabase's free→$25 pricing cliff. Any middle-tier options?

1 points by cgozdemm 2mo ago ↗ HN

Solo builder here. I'm running sqlquest.app — an adaptive SQL tutor — on Supabase's free tier since January. Traffic is tiny, maybe 10-20 real sessions a day. Every page load touches 5-6 tables though, and egress adds up quick when your app does state sync properly.

Went ~15% over the 5GB/month free egress cap. Instead of a soft warning or overage billing, the project hard-fails. Every API request returns 402. Login breaks. Signups break. Everything user-facing dies.

Two options: 1. Wait for the billing cycle to reset and hope the "short delay after reset" doesn't stretch into hours (it did) 2. Upgrade to Pro at $25/mo, instantly unblocked

I was 20 minutes from a live paid student demo when this hit. Paid the $25.

The $25 tier gives 250GB egress — 50× what I need. There's no middle ground for solo builders who've crossed the free cap but don't need enterprise headroom.

Questions for HN:

1. Has anyone else hit this? How'd you handle it? 2. Any existing workarounds (PostgREST + self-hosted, different provider with better pricing ladder)? 3. Is there a case to be made to Supabase for a $5-10/mo "solo" tier between Free and Pro? Or is the $25 tier strategically important for their unit economics?

Not trying to bash the product — I love the DX and I'm not switching. Just frustrated with the pricing jump. Curious if the community has opinions.

2 comments

[ 4.9 ms ] story [ 14.3 ms ] thread

kimhjo 2mo ago ↗

PlanetScale had the same issue before they killed their free tier entirely. The problem is these companies need a middle tier that's profitable, and $5-10/mo often isn't worth the support overhead for them.

For your use case, self-hosted Supabase on a $5 Fly.io or Railway instance might actually be cheaper long-term. You lose the managed DX but you get predictable costs. Neon is also worth looking at — their free tier is more generous on egress and they have a $19 launch tier that sits between free and full pro.

gajo357 2mo ago ↗

I’ve hit this exact issue with small projects, each app ends up needing its own DB. It is very hard to predict and calculate the usage in the provider's CU (I mainly used Azure and AWS).

I tried a few approaches: sharing one DB with schemas (gets messy over time), spinning things up/down (breaks things unpredictably), just paying and forgetting about it (feels wasteful).

Still haven’t found a setup that feels right for multiple small apps.

Did you come up with something?