Choosing a Database for Next.js

Database Landscape

Serverless and edge deployments change database requirements. This lesson covers connection pooling, latency tradeoffs, and why tools like PlanetScale, Neon, and Turso exist.

Integrating database engines in serverless architectures requires rethinking traditional database connection paradigms. In standard server environments (like Express on Node.js), a single persistent database connection pool remains open for the lifecycle of the process. In serverless platforms (like Vercel or AWS Lambda), every incoming request can spin up an isolated, ephemeral function container. If every request initiates a new TCP connection, standard databases (like vanilla PostgreSQL) quickly exceed their connection limits and crash. In this lesson, we will explore database structures, examine connection pooling mitigation steps, and analyze how serverless database engines enable high-scale Next.js architectures.

1. Relational vs. Non-Relational Databases in Next.js

Your database choices dictate how you write queries, enforce data integrity, and scale services:

Relational Databases (PostgreSQL, MySQL, SQLite): Enforce type safety, relational joins, and strict schema structures. Ideal for applications with complex linkages, like e-commerce ordering catalogs or transaction ledgers.
Non-Relational Databases (MongoDB, DynamoDB, Redis): Store data as schema-less JSON documents or key-value pairs. Best for unstructured data, logging stores, or quick application prototypes where schemas change frequently.

2. The Serverless Socket Exhaustion Problem

When a Server Component or Server Action queries a database, the execution container opens a connection. In a serverless container environment:

Vercel spins up hundreds of parallel instances of your functions to handle concurrent traffic.
Each function opens a direct connection socket to your database.
Traditional databases have a maximum socket limit (often around 100 to 500 connections).
Once this threshold is hit, database requests stall, causing API timeouts and server failures.

To resolve this, serverless database providers use HTTP connections or WebSocket proxies instead of raw TCP sockets.

3. Postgres on Serverless: Neon & Supabase

Neon and Supabase offer cloud-managed PostgreSQL designed explicitly for serverless. Neon separation of storage and compute allows it to scale down to zero when idle, saving resources. Both platforms provide connection pooling proxies (like PgBouncer) and HTTP-based query APIs that eliminate socket overhead.

// Example: Fetching Neon Postgres data via HTTP endpoint (Edge compatible)
export async function getNeonUsers() {
  const apiKey = process.env.NEON_DATABASE_URL;
  
  const res = await fetch('https://api.neon.tech/v1/projects/.../query', {
    method: 'POST',
    headers: {
      'Authorization': 'Bearer ' + apiKey,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      query: 'SELECT id, email FROM users LIMIT 10',
    }),
    next: { revalidate: 60 } // Cache results at Next.js layer
  });

  return res.json();
}

4. SQLite on the Edge: Turso

SQLite traditionally stores data in a local file. On serverless environments, this means data disappears when function containers spin down. Turso solves this by implementing libsql, a distributed fork of SQLite that syncs data across global edge instances, allowing your Edge middleware to run database queries with sub-millisecond latencies.

// Turso client initialization using HTTP transport
import { createClient } from '@libsql/client';

export const turso = createClient({
  url: process.env.TURSO_DATABASE_URL || 'libsql://...',
  authToken: process.env.TURSO_AUTH_TOKEN,
});

export async function fetchTursoLessons() {
  const result = await turso.execute('SELECT * FROM lessons');
  return result.rows;
}

5. MongoDB Atlas: Document Store Integration

MongoDB Atlas is the managed cloud database service for MongoDB. Because MongoDB uses connection handshakes that are lighter than relational databases, it performs well under serverless loads. However, you must still cache your connection client internally to prevent instantiating multiple connections during hot reloads.

// utils/mongodb.ts
import { MongoClient } from 'mongodb';

const uri = process.env.MONGODB_URI || 'mongodb://localhost:27017';
let client: MongoClient;
let clientPromise: Promise<MongoClient>;

if (process.env.NODE_ENV === 'development') {
  // Use a global variable to preserve the client across hot reloads in dev mode
  let globalWithMongo = global as typeof globalThis & {
    _mongoClientPromise?: Promise<MongoClient>;
  };

  if (!globalWithMongo._mongoClientPromise) {
    client = new MongoClient(uri);
    globalWithMongo._mongoClientPromise = client.connect();
  }
  clientPromise = globalWithMongo._mongoClientPromise;
} else {
  // In production, instantiate client on demand
  client = new MongoClient(uri);
  clientPromise = client.connect();
}

export default clientPromise;

6. Database Selection Matrix

Provider	Engine Type	Connection Method	Edge Compatibility	Best For
Neon / Supabase	PostgreSQL	HTTP Proxy / WebSockets	Excellent (via HTTP client)	Complex SaaS, structured relationships
Turso	libsql (SQLite)	HTTP API	Native Edge Runtime	Global users, rapid reads, edge components
MongoDB Atlas	Document Store	TCP Client Connection	Moderate (requires Node.js)	Log tracking, simple catalogs, JSON schemas

7. Caching Queries to Protect Database Limits

The most effective connection mitigation strategy is query caching. By using the Next.js fetch cache or React 19's cache() utility, you deduplicate database calls, preventing redundant requests from hitting your database engine:

// utils/db-queries.ts
import { cache } from 'react';

// cache() deduplicates requests made within the same page request cycle
export const getCachedProduct = cache(async (productId: string) => {
  // Run database query here
  const res = await fetch('https://api.progrumar.com/products/' + productId, {
    next: { revalidate: 600 } // Cache results on Vercel Edge for 10 minutes
  });
  return res.json();
});

8. The Cold Start Impact on Latency

When a database connection client is cold, the initial query must pay a connection handshake fee (establishing TLS/SSL security certificates). To minimize this impact, use regional deployments that place your serverless functions (e.g. us-east-1) in the same physical region as your database clusters.

9. Common Gotchas

Exceeding Connection Limits in Development: Next.js hot-reloads modified code during development. This process creates new database client connections without closing old ones, quickly hitting connection limits on local systems. Always use the global singleton pattern to preserve clients.
Running Raw Queries in Edge Middleware: Standard PostgreSQL drivers will fail inside Next.js Edge Middleware because they use Node-specific networking features. Only execute queries inside Middleware if using HTTP-based drivers (like Turso or Neon serverless packages).
Lack of Automatic Backups on Local SQLite: Storing SQLite databases inside your project folder is convenient for local development, but deploying that build to a serverless platform will reset the database file to blank on every deployment.

Key Takeaways

Serverless execution environments spin up multiple container instances, posing a risk of socket exhaustion on traditional database systems.
Use HTTP or WebSocket proxies (PgBouncer, Neon Serverless, Turso Client) to communicate with databases inside serverless routes.
Apply the global singleton pattern to preserve database clients across code edits in local development.
Deploy serverless regions as close to your database clusters as possible to minimize connection handshake latency.
Leverage query caching parameters inside Next.js to reduce total database hits.

Selecting the correct database engine establishes how your system handles scaling and network traffic. Now, let's learn how to interact with database schemas dynamically. In the next lesson, we will cover Prisma ORM with Next.js, setting up schemas, migrations, and executing type-safe queries.