Every side project hits the same question: where do I put the data? SQLite works for local development but falls apart when you deploy to serverless. Managed Postgres services work but charge you whether traffic is zero or ten thousand. NeonDB solves this by offering serverless Postgres that scales to zero and only charges for what you use.
This post covers when NeonDB is the right choice, how its branching feature changes development workflows, and the practical details of connecting it to serverless functions on Netlify and Vercel.
What NeonDB Is
NeonDB is a serverless Postgres provider that separates compute from storage. Your database is real Postgres — you can use any Postgres client, ORM, or tool you already know. The difference is that the compute layer (the thing that runs your queries) scales to zero when there is no traffic and spins up automatically when a request arrives.
The other defining feature is database branching. You can create a branch of your entire database — schema and data — in seconds. Make changes on the branch, test them, and merge or discard. It works like Git branches but for your database.
When to Use NeonDB vs the Alternatives
Choosing a database depends on your specific requirements. Here is how NeonDB compares:
NeonDB vs SQLite
SQLite is a single file. It is excellent for local development, CLI tools, and embedded applications. It falls apart when you need multiple serverless function instances to access the same data simultaneously — which is every serverless deployment. NeonDB gives you real Postgres accessible from any serverless function, any edge location, and any environment.
Choose SQLite when: You are building a local tool, a desktop app, or prototyping something that will never need concurrent access.
Choose NeonDB when: You are deploying to serverless and need concurrent database access from multiple function invocations.
NeonDB vs Supabase
Supabase bundles Postgres with auth, real-time subscriptions, edge functions, and file storage. NeonDB is just the database. If you need the full backend suite, Supabase is more convenient. If you already have auth (Clerk, Auth.js, custom) and just need a database, NeonDB is leaner and its branching feature is superior.
Choose Supabase when: You want an all-in-one backend with auth, storage, and real-time features.
Choose NeonDB when: You need a standalone database with branching and serverless scaling. Pair it with whatever auth and hosting you prefer.
NeonDB vs PlanetScale
PlanetScale was the other major serverless database contender, but it uses MySQL, not Postgres. If your stack is Postgres-native — and most modern frameworks are — NeonDB is the natural fit. PlanetScale also introduced pricing changes that pushed many side projects off its free tier. NeonDB's free tier is more generous for small projects.
Database Branching for Development
This is the feature that makes NeonDB different from every other managed Postgres. When you create a branch, NeonDB uses copy-on-write to create an instant copy of your database. No data duplication until you actually change something.
Practical use cases:
Preview deployments. Every Vercel or Netlify preview deployment can get its own database branch. Test schema migrations against real data without touching production.
Feature development. Create a branch for each feature. Run migrations, seed test data, and verify everything works. If it does, merge the migration into main. If it does not, delete the branch.
Safe migrations. Before running ALTER TABLE on production, run it on a branch first. Verify the migration completes without errors and the application still works.
Here is how to create and use branches with the Neon CLI:
# Install the Neon CLI
npm install -g neonctl
# Authenticate
neonctl auth
# Create a branch from main
neonctl branches create --name feature-user-settings
# Get the connection string for the branch
neonctl connection-string feature-user-settings
# Delete a branch when done
neonctl branches delete feature-user-settings
Connecting from Netlify Functions
Netlify Functions run as AWS Lambda under the hood. Connecting to NeonDB requires the @neondatabase/serverless driver, which is optimized for serverless environments with WebSocket connections instead of TCP.
// netlify/functions/get-projects.js
import { neon } from '@neondatabase/serverless';
export async function handler(event) {
const sql = neon(process.env.DATABASE_URL);
const projects = await sql`
SELECT id, name, created_at
FROM projects
WHERE user_id = ${event.queryStringParameters.userId}
ORDER BY created_at DESC
LIMIT 20
`;
return {
statusCode: 200,
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(projects)
};
}
Set DATABASE_URL in your Netlify environment variables to your NeonDB connection string. The @neondatabase/serverless driver handles connection pooling automatically — you do not need PgBouncer or a separate connection pooler.
Connecting from Vercel Serverless Functions
The setup is nearly identical. Vercel also runs serverless functions on AWS Lambda, and the NeonDB driver works the same way:
// app/api/projects/route.ts (Next.js App Router)
import { neon } from '@neondatabase/serverless';
import { NextResponse } from 'next/server';
export async function GET(request: Request) {
const sql = neon(process.env.DATABASE_URL!);
const { searchParams } = new URL(request.url);
const userId = searchParams.get('userId');
const projects = await sql`
SELECT id, name, status, created_at
FROM projects
WHERE user_id = ${userId}
ORDER BY created_at DESC
`;
return NextResponse.json(projects);
}
Vercel also supports NeonDB's @vercel/postgres package, which is a thin wrapper around the NeonDB driver with Vercel-specific optimizations.
Auto-Scaling and Cold Starts
NeonDB scales compute to zero after five minutes of inactivity on the free tier. When the next query arrives, the compute endpoint "wakes up" — this is the cold start.
Cold start times for NeonDB are typically 300-500 milliseconds. That is noticeable for the first request but irrelevant for subsequent requests while the compute is warm. For most side projects and low-traffic sites, this is acceptable.
If cold starts are a problem:
- Pro tier lets you configure a minimum compute size so the database never fully scales to zero
- Connection pooling with the serverless driver reduces overhead on warm starts
- Keep-alive pings (a cron job that queries the database every 4 minutes) prevent cold starts entirely, though this uses compute time
Free Tier Limits
NeonDB's free tier as of 2026:
| Resource | Free Tier Limit |
|---|---|
| Projects | 1 |
| Branches | 10 |
| Storage | 512 MB |
| Compute hours | 191.9 hours/month |
| Autosuspend | After 5 min inactive |
191.9 compute hours sounds limited, but because the database scales to zero when idle, most side projects use a fraction of this. A site that gets 1,000 queries per day might use 10-15 compute hours per month.
When to upgrade: If you hit the 512 MB storage limit, need more than 10 branches, or need the database to stay warm for low-latency production workloads. The Launch plan starts at $19/month.
Schema Design Tips for Serverless
Serverless database connections are short-lived. Design your schema to minimize round trips:
Use fewer, wider queries. Instead of querying three tables separately, join them in a single query. Each round trip to the database has latency, especially on cold starts.
-- Instead of three separate queries, use a join
SELECT
p.id, p.name,
u.email,
COUNT(t.id) as task_count
FROM projects p
JOIN users u ON u.id = p.user_id
LEFT JOIN tasks t ON t.project_id = p.id
WHERE p.user_id = $1
GROUP BY p.id, u.email;
Index aggressively. Serverless functions have tight time limits (10-30 seconds depending on platform). Slow queries that would be tolerable on a persistent server become timeouts in serverless. Add indexes for every column you filter or join on.
Use connection pooling. Always use the @neondatabase/serverless driver instead of the standard pg driver. It handles pooling and connection reuse automatically.
Migration from Other Databases
Moving to NeonDB from another Postgres provider is straightforward because it is standard Postgres. Use pg_dump and pg_restore:
# Dump from existing Postgres
pg_dump -h old-host -U old-user -d old-database -F c -f backup.dump
# Restore to NeonDB
pg_restore -h your-neon-host.neon.tech -U your-neon-user -d neondb backup.dump
Migrating from MySQL or SQLite requires a schema conversion tool like pgloader or manual migration. If you are using an ORM like Prisma or Drizzle, update the connection string and run your migrations — the ORM handles the rest.
Where This Fits in the Digital Empire
If you are building tools and SaaS products following the methodology in The $97 Launch, NeonDB is the database layer for anything that needs persistent data storage beyond what the browser can handle. Start with static sites and free browser-based tools. When you need a database — for user data, saved reports, or any server-side logic — NeonDB's free tier lets you add that capability without upfront cost.
Pair NeonDB with Netlify or Vercel for hosting, add Supabase or Clerk for auth if needed, and you have a full-stack application that costs nothing until you have paying users. That is the kind of infrastructure that makes the Digital Empire approach work.