Supabase vs Neon: which free Postgres should you build on?

Published 2026-10-06

TESTED — measured, not copied from pricing pages

If you need a free Postgres database for a new project, you are basically choosing between Supabase and Neon right now. Both offer genuinely free tiers with no credit card. Both run real PostgreSQL.

They solve different problems. Supabase is an all-in-one backend (Postgres plus auth, storage, and edge functions). Neon is pure serverless Postgres focused on branching and scale-to-zero.

We didn’t just read the pricing pages — we created a project on each, connected from India, and measured what actually happens. Numbers below are from our own runs on 2026-10-06.

The verdict table

* Supabase’s free instance doesn’t scale to zero on short timescales — our “cold” number is a fresh connection after 6 minutes idle. Its real pause only kicks in after 7 days of inactivity and requires a manual dashboard restore.

How we measured

We created a fresh free project on each platform — Supabase in Mumbai (ap-south-1), Neon in Singapore (ap-southeast-1, its closest region to India) — and ran the same script from a machine in India:

1. Cold: first connection + SELECT 1 after 6 minutes of idle (beyond Neon’s 5-minute suspend)
2. Warm: 5 fresh connections while compute is up
3. Hot: 5 queries on an already-open connection

The measurement script is in our repo — run it yourself.

What the numbers mean

Neon pays a real cold-start tax

Neon’s compute suspends after 5 minutes of inactivity — not configurable on the free plan. The next request pays ~1.2 seconds from India. If your app gets a request every few minutes, every one of those users waits. If it gets steady traffic, the compute stays warm and you never notice — but then you’re burning through the 100 CU-hour monthly allowance (0.25 CU × 400 hours = the whole month, so steady traffic fits, but background jobs plus traffic may not).

Supabase’s free instance is a small always-on server. No suspend cycle, no cold-start tax — until the 7-day pause, which is a different beast entirely: the project stops until you log into the dashboard and restore it by hand.

The 10x latency gap is geography, not engineering

Supabase’s 5 ms vs Neon’s 58 ms hot-query latency is almost entirely Mumbai vs Singapore round-trip time. Neither platform is “slower” — Neon just has no India region. If your users are in India, that 50+ ms on every single query is a tax you pay forever. If your users are in the US or EU, this flips and you should re-run our script from where your server will live.

Gotcha we hit: Supabase direct connections are IPv6-only

Our first connection attempt to Supabase failed with ENETUNREACH. The direct connection string (db.<ref>.supabase.co) resolves to IPv6 only, and most Indian home ISPs don’t route IPv6. Use the session pooler string (<ref>.pooler.supabase.com) — it’s IPv4-friendly. If a tutorial just gives you the direct string and you’re on IPv4, you’ll think the service is down. It isn’t.

Verified limits

Supabase free tier

• 2 active projects, 500 MB Postgres each (including indexes and WAL overhead — usable space is less)
• Auth: 50,000 monthly active users
• Storage: 1 GB files; egress 5 GB/month; 500K edge function invocations
• Paused after 7 days inactivity, restorable from dashboard
• No automated backups — if you drop a table, it’s gone

Neon free tier

• 100 projects, 1 GB Postgres each, 20 GB account-wide cap
• 100 CU-hours compute per project per month; autoscaling up to 2 CU
• 10 branches per project (database branches work like git branches)
• Egress 5 GB/project/month; 6-hour instant-restore history (capped at 1 GB of changes)
• Run out of CU-hours mid-month and your compute is suspended until next month — data survives, app goes down
• Hit the storage cap and writes start failing until you free space

Note: many posts still cite Neon’s old “512 MB per branch” limit. The current official number is 1 GB per project — we verified against Neon’s plans doc on 2026-10-06.

Which one should you pick?

Student side project: Supabase. Auth and file uploads out of the box means you ship the actual project instead of wiring JWT handling all weekend. Ping it once a week so it doesn’t pause (a free cron from GitHub Actions works).

Indie hacker production app: Neon — if your traffic is sporadic and your users aren’t latency-sensitive. Database branching makes migrations genuinely safer: branch, migrate, test, merge. If you use Clerk/Auth0 or your own backend anyway, Supabase’s extras are dead weight. But watch the CU-hour budget if you run background jobs.

India-based users: Supabase, and it’s not close. 5 ms vs 58 ms on every query, measured. Until Neon opens an India region, physics wins.

When the answer is “pay for neither”

• You need predictable latency with zero cold starts and zero pause risk → a $5-6/mo VPS running Postgres in Docker beats both free tiers
• Your database is already over 500 MB–1 GB → you’re outside both free tiers on day one
• You need real backups and point-in-time recovery guarantees → that’s a paid feature everywhere

What we actually ran this on

• Client machine: Linux x86_64, Node.js 24, pg driver, IPv4-only home connection in India
• Supabase project: Mumbai ap-south-1, session pooler connection
• Neon project: Singapore ap-southeast-1, pooled connection string, fixed 0.25 CU
• Method: 1 cold run after 360 s idle, 5 warm connections, 5 hot queries per service; medians reported
• Date: 2026-10-06