Neon vs Supabase: Comparing Serverless Postgres

Neon and Supabase both offer managed PostgreSQL, but comparing them as "Postgres hosting options" misses the point. They're solving different problems for different developers. Neon is reimagining what PostgreSQL infrastructure can be. Supabase is reimagining what a backend platform can include.

I've used both in production. The right choice depends entirely on what you're actually building.

Origin Stories

Supabase started in 2020 when Paul Copplestone and Ant Wilson launched on Hacker News with a bold claim: an open-source Firebase alternative. Firebase had dominated backend-as-a-service for years, but developers had complaints: proprietary database, unpredictable pricing, vendor lock-in. Supabase bet that PostgreSQL could be the foundation for something better.

The launch resonated. Developers frustrated with Firestore's limitations saw Supabase as a way to get the convenience of Firebase with a real relational database underneath. The project grew fast, raised significant funding, and built out authentication, storage, edge functions, and auto-generated APIs: all on top of Postgres.

Neon emerged from a different problem. Nikita Shamgunov, who'd previously co-founded MemSQL (now SingleStore), saw an opportunity to rethink PostgreSQL architecture. Traditional Postgres ties compute and storage together. Your database server both processes queries and stores data. What if you separated them?

Neon's architecture puts storage on a distributed, log-based system and runs compute nodes separately. This enables features that traditional Postgres can't match: instant branching (copy a database in milliseconds), scale-to-zero (stop paying when idle), and autoscaling (add compute on demand). It's Postgres, but rebuilt for the cloud era.

What You're Choosing Between

Supabase gives you a backend.

When you create a Supabase project, you get:

• PostgreSQL database with connection pooling
• Authentication (email, OAuth, magic links, phone)
• File storage (S3-compatible)
• Edge Functions (Deno runtime)
• Auto-generated REST and GraphQL APIs
• Real-time subscriptions to database changes
• Row-level security deeply integrated with auth
• A dashboard for managing everything

For a solo developer or small team building a web or mobile app, this is powerful. You can go from zero to deployed backend in an afternoon. Auth that works with your database's row-level security? Built in. File uploads with access control? Included. REST API for your tables? Automatic.

Neon gives you PostgreSQL infrastructure.

When you create a Neon project, you get:

• PostgreSQL database
• Connection pooling via their proxy
• Branching (instant copies of your database)
• Scale-to-zero compute
• Point-in-time recovery

That's it. No auth, no file storage, no edge functions. Just PostgreSQL, done exceptionally well.

The Serverless Difference

"Serverless" means different things to each platform.

Neon's serverless is architectural. The separation of compute and storage enables things traditional Postgres can't do:

Scale to zero: If your database has no queries for a few minutes, Neon suspends the compute. You stop paying for CPU. When a query arrives, it starts up (cold start is around 500ms).

For a hobby project that gets occasional traffic, or a development database you only use during work hours, this is real money savings. A traditional database runs 24/7 whether you query it or not.

Instant branching: This is Neon's killer feature. Creating a branch is like git branch for your database, instant, regardless of database size.

# Create a branch from production
neon branches create --name feature-experiment --parent main

# The branch has all production data, ready instantly
# Uses copy-on-write storage, so it's efficient

Use cases are compelling:

• Every pull request gets a preview database with real data
• Test migrations against production-like data without risk
• Create throwaway environments for debugging
• Let developers experiment without affecting shared databases

This changes workflows. No more "can I get a copy of the production database?" taking hours.

Supabase's serverless is about abstraction. The database itself runs on traditional dedicated compute (though the free tier pauses after inactivity). But the services built on top (Edge Functions, Storage, Auth) are serverless in the sense that you don't manage servers.

Supabase recently introduced their own connection pooler (Supavisor) and has been working on more serverless-style features, but the architecture is fundamentally different from Neon's.

Developer Experience

Supabase's dashboard is comprehensive. You can:

• Write and execute SQL directly
• Browse tables like a spreadsheet
• Manage auth users and providers
• Upload and organize files
• Monitor database performance
• Configure row-level security policies

The client libraries are well-designed and typed:

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(url, anonKey);

// Auth
const { data: { user } } = await supabase.auth.signInWithPassword({
  email: 'alice@example.com',
  password: 'secret'
});

// Database with types
const { data: posts } = await supabase
  .from('posts')
  .select('*, author:profiles(*)')
  .eq('published', true);

// Real-time subscriptions
supabase
  .channel('posts')
  .on('postgres_changes', { event: 'INSERT', schema: 'public', table: 'posts' },
    payload => console.log('New post:', payload.new))
  .subscribe();

Neon's experience is database-focused. The dashboard is clean and functional but limited to database operations. The CLI is powerful for branching workflows:

# Create a branch for PR #123
neon branches create --name pr-123 --parent main

# Get connection string for the branch
neon connection-string pr-123

# Delete branch after PR merge
neon branches delete pr-123

For connecting, you use any PostgreSQL client library:

import { Pool } from 'pg';

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  // Neon's pooler handles connection management
});

const result = await pool.query(
  'SELECT * FROM posts WHERE published = $1',
  [true]
);

There's no Neon-specific client. It's just Postgres. Any ORM, any tool, any library that works with PostgreSQL works with Neon.

Real-Time Features

Supabase has real-time subscriptions built on PostgreSQL's replication features:

// Subscribe to changes on a table
supabase
  .channel('todos')
  .on('postgres_changes',
    { event: '*', schema: 'public', table: 'todos' },
    payload => {
      console.log('Change:', payload);
    })
  .subscribe();

This is genuinely useful for collaborative features, live dashboards, and reactive UIs. It's not as polished as Firebase's real-time database, but it works and it's built on Postgres.

Neon doesn't have real-time subscriptions. It's infrastructure, not a platform. If you need real-time features, you'd add a separate service (Pusher, Ably, or roll your own with WebSockets).

Authentication and Row-Level Security

This is where Supabase's platform approach shines.

Supabase Auth integrates with PostgreSQL's row-level security:

-- Users can only see their own data
CREATE POLICY "Users see own data" ON user_data
  FOR SELECT USING (auth.uid() = user_id);

-- Users can only update their own data
CREATE POLICY "Users update own data" ON user_data
  FOR UPDATE USING (auth.uid() = user_id);

The auth.uid() function returns the authenticated user's ID from the JWT token. Policies are enforced at the database level. Your API layer doesn't need to check permissions.

This is powerful when it fits your mental model. Security rules live in one place (the database), are enforced consistently, and can't be bypassed by application bugs.

Neon has no authentication layer. You'd use a separate service (Auth0, Clerk, NextAuth, etc.) and implement authorization in your application or write your own RLS policies with a custom auth schema.

Pricing Models

Neon Free Tier:

• 0.5 GB storage
• 191 compute hours per month
• Unlimited projects
• Branching included
• Scale-to-zero works on free tier

Neon Pro ($19/month):

• 10 GB storage included
• 300 compute hours included
• Pay for additional usage
• Longer history retention for branching

Supabase Free Tier:

• 500 MB database storage
• 1 GB file storage
• 50,000 monthly active users (auth)
• 500,000 Edge Function invocations
• Pauses after 1 week of inactivity

Supabase Pro ($25/month):

• 8 GB database storage
• 100 GB file storage
• No pause, daily backups
• 7-day log retention

The pricing philosophies differ. Neon charges for compute time, ideal for variable workloads. Supabase charges for resources, more predictable but you pay whether you use them or not.

For a hobby project that runs occasionally, Neon's free tier with scale-to-zero might cost nothing. Supabase would pause after a week, which is fine but less elegant.

For a production app with consistent traffic, Supabase's bundled features (auth, storage, functions) might be cheaper than paying for Neon plus separate services for each.

When to Choose Neon

You need just PostgreSQL. If you have an existing auth system, your own file storage, and just need a database, Neon gives you excellent Postgres without paying for features you won't use.

Database branching is valuable. If your team would benefit from instant database copies for previews, testing, or development isolation, this feature alone might justify Neon.

Variable or spiky workloads. If your database is idle most of the time (dev environments, side projects, occasional-use internal tools), scale-to-zero saves money.

Existing backend infrastructure. If you're adding Postgres to an existing system rather than building from scratch, Neon fits without requiring you to adopt a new platform.

Multi-database architectures. If you need many small databases (multi-tenant SaaS, microservices), Neon's model of cheap-to-create, cheap-when-idle databases works well.

When to Choose Supabase

You need a complete backend. If you're starting a new app and need auth, database, storage, and APIs, Supabase gives you all of it in one platform.

Firebase migration. If you're coming from Firebase and want something similar but with a real database, Supabase is the obvious choice.

Row-level security matters. If you want authorization enforced at the database level, integrated with authentication, Supabase's RLS integration is elegant.

Real-time features. If your app needs live updates (collaborative editing, dashboards, notifications), Supabase's real-time subscriptions are built in.

Rapid prototyping. If you want to go from idea to working demo as fast as possible, Supabase's auto-generated APIs and dashboard get you there.

The Hybrid Approach

Some teams use both:

• Supabase for production: Full platform, stable, everything integrated
• Neon for development: Branching, cheap preview environments, isolated testing

Since both are PostgreSQL, migrating between them is straightforward. Your schema, your data, your queries: all portable.

What This Really Comes Down To

Neon and Supabase aren't competing for the same use case. They're both excellent at what they do.

If you're thinking "I need a database," Neon is probably the better fit. It's focused, it's innovative, and it does one thing exceptionally well.

If you're thinking "I need a backend," Supabase is probably the better fit. It's comprehensive, it's productive, and it saves you from integrating multiple services.

The mistake is choosing one when you need the other. Don't pick Neon if you're going to reinvent authentication, file storage, and real-time from scratch. Don't pick Supabase if you just want a database and will ignore 80% of its features.

Understand what you're building, then choose the tool that matches.