Supabase vs Neon: I measured both free Postgres tiers from India

Originally published on FreeTierWatch, where we hand-verify and track the free tiers of developer services.

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 (Free)	Neon (Free)
Credit card required	No	No
Postgres storage	500 MB per project (2 projects)	1 GB per project, 20 GB account total
Compute model	Always-on shared instance	Scale-to-zero, 100 CU-hours/project/month
Idle policy	Project paused after 7 days inactivity	Compute suspends after 5 minutes (resumes automatically)
Cold start (measured)	495 ms*	1,242 ms
Hot query from India (measured)	5 ms (Mumbai)	58 ms (Singapore)
India region	Yes — Mumbai ap-south-1	No — Singapore closest
Bundled extras	Auth (50k MAU), 1 GB file storage, edge functions	Branching, 60k MAU auth, object storage
Backups	None on free	6-hour restore history (1 GB cap)

* 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

	cold	warm connect (median)	hot query (median)
Neon (Singapore)	1,242 ms	431 ms	58 ms
Supabase (Mumbai)	495 ms	238 ms	5 ms

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

Comments

[Vlad Tkachenko]

Since the GitHub Actions cron is there for the weekly ping anyway, the same job can cover the backup row in your table, which is also what Supabase's backup docs tell free projects to do: export regularly with supabase db dump and keep the copies off-site. Your IPv6 gotcha applies there too. Supabase lists GitHub Actions among the IPv4-only platforms, so the job needs the session pooler string. One trap when setting it up: supabase db dump on its own writes the schema and no rows. The guide does three files (roles, schema, and data with --data-only), and the data one is what you'd want after a dropped table.

[karthik]

Great addition — thanks. You're right on all three counts: one GitHub Actions cron can do double duty (keepalive ping + supabase db dump), GitHub runners are IPv4-only so the session pooler string is mandatory there too, and the schema-only default of db dump is exactly the trap that bites you the day you actually need the backup. The three-file split (roles / schema / --data-only) is the right pattern.

Folding this into the article's backup note. This is precisely the failure mode that matters on free tiers: no managed backups means the DIY backup had better actually contain the data.