Why Neon Over Supabase and PlanetScale

Choosing a database provider feels like choosing a foundation — get it wrong, and you're rebuilding later. The serverless database landscape has matured significantly, with three major players dominating the conversation: Neon, Supabase, and PlanetScale.

For Eden Stack, I chose Neon. Here's the reasoning — and why it matters for a template designed to be flexible.

PostgreSQL: The Undisputed Leader

Before comparing providers, let's address the engine question: PostgreSQL has won.

The 2024 Stack Overflow Developer Survey tells the story clearly:

PostgreSQL isn't just popular — it's pulling away. Usage grew from 45% in 2023 to nearly 52% in 2024. The gap with MySQL widened from 8.5 to 12.5 percentage points in a single year.

Why the dominance? PostgreSQL offers:

• Superior JSON support for modern applications
• Advanced indexing (GIN, GiST, BRIN)
• Full-text search built-in
• pgvector for AI embeddings
• Rich extension ecosystem
• Battle-tested reliability

For Eden Stack — a template for modern, AI-native applications — PostgreSQL was the obvious choice. The question became: which PostgreSQL provider?

PlanetScale: The MySQL Exception

Let's address PlanetScale first: it's MySQL, not PostgreSQL.

PlanetScale built an excellent product around Vitess, MySQL's horizontal scaling solution. Their branching workflow is genuinely innovative, and the developer experience is polished.

But here's the issue: choosing PlanetScale means choosing MySQL. In 2025, that's swimming against the current:

• Most modern ORMs optimize for PostgreSQL first
• AI/ML features (vector search) have better PostgreSQL support
• The developer community is consolidating around PostgreSQL
• Future hiring favors PostgreSQL experience

PlanetScale also made concerning pricing changes in 2024, removing their free tier and repositioning as enterprise-focused. For a startup template, that's a red flag.

Verdict: PlanetScale is excellent if you need MySQL specifically. For everything else, PostgreSQL providers make more sense.

Supabase: The All-in-One Platform

Supabase positions itself as "the open-source Firebase alternative." It's PostgreSQL-based and offers an impressive feature set:

• PostgreSQL database with a nice dashboard
• Built-in authentication (Supabase Auth)
• Real-time subscriptions
• Edge Functions
• Object storage
• Vector support

If you want an all-in-one platform, Supabase delivers. The integration is tight, the dashboard is excellent, and the community is vibrant.

The Vendor Lock-In Problem

Here's my concern with Supabase: the value is in the ecosystem, not just the database.

// Supabase encourages this pattern
import { createClient } from '@supabase/supabase-js';
 
const supabase = createClient(url, key);
 
// Auth through Supabase
const { user } = await supabase.auth.signInWithOAuth({ provider: 'google' });
 
// Database through Supabase
const { data } = await supabase.from('users').select('*');
 
// Storage through Supabase
const { data: file } = await supabase.storage.from('avatars').upload(path, file);

Each feature pulls you deeper into the Supabase ecosystem. The database itself is standard PostgreSQL, but:

• Supabase Auth isn't portable — migrate means rebuilding auth
• Real-time subscriptions use Supabase-specific protocols
• Storage is Supabase-proprietary
• Row-level security is configured through their dashboard

None of this is bad. If you're committed to Supabase long-term, the integration is a feature. But for a template designed to let developers choose their own components, this coupling works against flexibility.

The Philosophical Difference

Eden Stack's philosophy: high-quality building blocks you can swap.

• Use Better Auth? Swap it for Clerk if you want.
• Use Neon? Move to AWS RDS if you need.
• Use Inngest? Replace with BullMQ if that fits better.

Supabase's philosophy: use our integrated platform for everything.

Both are valid approaches. They're optimizing for different goals.

Neon: PostgreSQL, Focused

Neon does one thing: serverless PostgreSQL, done exceptionally well.

// Neon: Just PostgreSQL
import { neon } from '@neondatabase/serverless';
 
const sql = neon(process.env.DATABASE_URL);
const users = await sql`SELECT * FROM users WHERE id = ${userId}`;

Or with Drizzle:

import { drizzle } from 'drizzle-orm/neon-http';
import { neon } from '@neondatabase/serverless';
 
const sql = neon(process.env.DATABASE_URL);
const db = drizzle(sql);
 
// Standard Drizzle queries — no Neon-specific code
const users = await db.select().from(usersTable);

What Neon Does Well

1. True Serverless Scaling

Neon scales to zero when inactive and wakes instantly. You pay for what you use, not for idle capacity. This matters for:

• Development branches that sit unused
• Side projects with sporadic traffic
• Cost-conscious startups

2. Database Branching

Like Git for your database:

# Create a branch for feature development
neon branch create --name feature-xyz
 
# Each branch is a full copy, instantly available
# Test migrations without touching production

This workflow is transformative for teams. Test schema changes on a branch, verify they work, then merge. No more "I hope this migration doesn't break prod."

3. Generous Free Tier

• 0.5 GB storage
• 190 compute hours/month
• Unlimited projects and branches

For development and small production workloads, you might never pay anything.

4. Provider Agnostic by Design

Here's the key insight: Neon is just PostgreSQL.

Your application code doesn't know it's talking to Neon. The connection string works with any PostgreSQL client. When you outgrow Neon or need different infrastructure, you can migrate to:

• AWS RDS
• Google Cloud SQL
• Azure Database for PostgreSQL
• Self-hosted PostgreSQL
• Any other PostgreSQL host

Your Drizzle schema stays the same. Your queries stay the same. The migration is a connection string change and a data export/import.

The Provider-Agnostic Architecture

This is Eden Stack's database philosophy:

Drizzle provides the ORM abstraction. PostgreSQL provides the protocol standard. Neon provides a great default. But nothing in your codebase is Neon-specific except the connection string.

Compare to Supabase:

The database is portable, but everything around it isn't.

When to Choose What

Choose PlanetScale when:

• You specifically need MySQL (legacy requirements, existing expertise)
• Vitess-level horizontal scaling is a requirement
• You're enterprise and price isn't a concern

Choose Supabase when:

• You want an all-in-one platform and embrace the ecosystem
• Real-time features are central to your application
• You prefer dashboard-driven configuration
• Vendor lock-in isn't a concern

Choose Neon when:

• You want PostgreSQL without ecosystem lock-in
• Provider flexibility matters for your roadmap
• Serverless scaling and branching fit your workflow
• You're using a separate ORM (Drizzle, Prisma)
• Cost efficiency is important

Why Eden Stack Uses Neon

For a template designed around flexibility and modern best practices:

1. PostgreSQL is the standard — 52% of developers, growing fast
2. Provider agnostic — Swap Neon for any PostgreSQL host
3. Pairs with Drizzle — ORM handles the abstraction, Neon handles hosting
4. Serverless-native — Scales to zero, instant branching
5. Generous free tier — Build without paying until you're ready

Neon provides the database Eden Stack needs without dictating the rest of your infrastructure. That's the goal: strong defaults, easy swaps.

Your database is PostgreSQL. Your ORM is Drizzle. Your host starts with Neon. If any of those need to change, they can — independently.

This post reflects my opinions after evaluating serverless database options. Supabase and PlanetScale are excellent products — this isn't about them being bad, but about Neon being a better fit for Eden Stack's provider-agnostic philosophy.