Neon vs Supabase

What's Being Traded Off

The core trade-off is depth vs. breadth.

Neon does one thing: serverless PostgreSQL, done exceptionally well. Scale-to-zero, instant branching, purpose-built serverless driver, zero vendor-specific behavior. Your ORM, auth, and storage choices remain yours.

Supabase bundles a database with auth, storage, edge functions, and realtime. The database is PostgreSQL underneath, but the platform wraps it with Supabase-specific APIs. You gain speed at the start; you trade portability long-term.

The trap: choosing Supabase for the auth feature, then gradually coupling your entire data access layer to Supabase's client SDK — making the eventual "just the database" migration much harder.

Where Each Wins Clearly

Neon wins when:

• Using Drizzle or Prisma as your ORM (much cleaner integration)
• You need branch-per-PR database state for CI/CD workflows
• You want zero lock-in — pure Postgres you can migrate anywhere
• Your stack already handles auth (Clerk) and storage separately

Supabase wins when:

• You want auth, database, storage, and realtime in one dashboard
• Your team doesn't want to wire up Clerk or Auth.js separately
• You're building a mobile backend that benefits from Supabase's client SDKs
• Realtime data sync is a core feature, not an afterthought

The Hidden Cost of the All-in-One Choice

Supabase's free tier pauses inactive projects after one week. For an MVP you're actively building, this means waking up a paused database every Monday. Neon's free tier never pauses.

More significantly: if you use Supabase's auth, Row Level Security policies, storage buckets, and realtime subscriptions, you're not just using a database — you've built on a platform. Migrating away later means migrating auth providers, rewriting storage logic, and replacing realtime infrastructure. What looked like "just a database" is now a vendor dependency across your entire backend.

AI Coding Fit

Neon + Drizzle is significantly better for AI-assisted development. Drizzle's SQL-like API is well-represented in AI training data. AI tools reliably generate correct Drizzle schema definitions, migrations, and queries against Neon.

Supabase's JavaScript client uses its own query builder (supabase.from('table').select()). When combined with Row Level Security, AI tools frequently generate incorrect code or miss the auth context required for RLS policies to work. If you use Supabase with Drizzle (instead of the Supabase client), the AI generation quality improves — but then you're not using Supabase's distinguishing features.

Vendor Lock-In

Neon: minimal. Your schema is standard PostgreSQL. Your migrations run with drizzle-kit. You can move to any Postgres host with pg_dump/pg_restore. Connection string changes, nothing else.

Supabase: meaningful. The database itself is portable, but auth (GoTrue), storage (separate service), and realtime (Phoenix channels) are Supabase-specific. Migrating is a multi-system project, not a database migration.

Migration Pain

Neon → another Postgres: Near-zero. Standard pg_dump. Any Drizzle migrations work unchanged.

Supabase → Neon (database only): Low. Export data, run migrations against Neon, update connection string.

Supabase → Neon (full platform): High. You're also migrating auth to Clerk/Auth.js, storage to Cloudflare R2/Vercel Blob, and realtime to Pusher/Ably. Plan weeks, not hours.

Final Recommendation

Use Neon if you're using Drizzle or Prisma, want zero lock-in, or need branch-per-PR database state. The serverless driver performance is best-in-class for Next.js.

Use Supabase if you genuinely want one dashboard for everything and you're not building a system that will need to migrate providers. Accept the lock-in as a deliberate trade-off, not an oversight.

Prompt Starter

I'm using [Neon / Supabase] with Drizzle ORM and Next.js App Router.

Help me [set up the connection / write a migration / optimize a query] with:
- [specific requirements]

Use the @neondatabase/serverless driver for Neon.
Use the Drizzle adapter, not the Supabase client.