Full-Stack Next.js with Prisma and Postgres

Next.js 15 (App Router, React 19) for the framework, Prisma 6 as the type-safe DB client, Postgres as the DB, Neon (or any Postgres) for hosting, Vercel for deploys, Auth.js v5 (NextAuth) for sessions. This combo lets one developer ship a real product in a weekend and lets a team scale it without rewriting.

The shape we're building toward: Server Components read Postgres directly, Server Actions write to Postgres, the client only re-renders to reflect changes — no useEffect fetches, no separate API layer. The browser bundle shrinks; the code is roughly half the volume of an Express + React + axios + Redux app for the same features.

The schema is the source of truth. Run pnpm dlx prisma init then edit prisma/schema.prisma:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model Todo {
  id        String   @id @default(cuid())
  title     String
  done      Boolean  @default(false)
  userId    String
  createdAt DateTime @default(now())
  @@index([userId, createdAt])
}

pnpm prisma generate writes a fully typed client into node_modules/@prisma/client. Now db.todo.findMany({ where: { userId } }) is typed end-to-end — return type, filter shape, the lot.

Two ways to apply a schema change:

• prisma db push — sync the DB to the schema without recording a migration. Great for prototyping and for branch dbs.
• prisma migrate dev --name add_todo_done — generates a versioned SQL migration in prisma/migrations/, applies it, and updates the migration history table.

In production you always want migrations. They're committed to git, code-reviewable, and replayable: prisma migrate deploy in CI applies any pending migrations against the production DB in order. Use db push for local hacking, switch to migrations the moment more than one person touches the schema.

Next.js dev mode re-evaluates your module graph on every change. Naively new PrismaClient() per import leaks connections until your DB rejects new ones. Use this singleton pattern:

// lib/db.ts
import { PrismaClient } from '@prisma/client';

const globalForPrisma = globalThis as unknown as { prisma?: PrismaClient };

export const db =
  globalForPrisma.prisma ??
  new PrismaClient({ log: ['error', 'warn'] });

if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = db;

In production each instance gets one client; in dev the global stashes it across HMR reloads. This is the #1 "why am I out of DB connections?" cause for Next.js newcomers.

With the singleton in place, a Server Component reads Postgres in one line:

// app/todos/page.tsx
import { db } from '@/lib/db';
import { auth } from '@/auth';
import { TodoList } from './todo-list';

export default async function TodosPage() {
  const session = await auth();
  if (!session) return <p>Sign in.</p>;
  const todos = await db.todo.findMany({
    where: { userId: session.user.id },
    orderBy: { createdAt: 'desc' },
  });
  return <TodoList initial={todos} />;
}

No loading state, no fetcher, no API route, no useQuery. The page awaits the DB on the server, streams HTML to the browser, and hands a typed array to a Client Component for interactivity.

Mutations live in 'use server' files. They run on the server, get full DB access, and revalidate the relevant route afterward.

// app/todos/actions.ts
'use server';
import { z } from 'zod';
import { revalidatePath } from 'next/cache';
import { db } from '@/lib/db';
import { auth } from '@/auth';

const Create = z.object({ title: z.string().min(1).max(120) });

export async function addTodo(formData: FormData) {
  const session = await auth();
  if (!session) throw new Error('unauthorized');
  const { title } = Create.parse({ title: formData.get('title') });
  await db.todo.create({ data: { title, userId: session.user.id } });
  revalidatePath('/todos');
}

export async function toggleTodo(id: string) {
  const t = await db.todo.findUnique({ where: { id } });
  if (!t) return;
  await db.todo.update({ where: { id }, data: { done: !t.done } });
  revalidatePath('/todos');
}

That's the entire write side of a CRUD feature. No Express, no fetch, no JSON marshalling.

Server Actions feel slower than they are because the user waits for the round-trip. useOptimistic lets you paint the new state immediately and reconcile when the server confirms.

'use client';
import { useOptimistic } from 'react';
import { addTodo } from './actions';

export function TodoList({ initial }: { initial: Todo[] }) {
  const [todos, addOptimistic] = useOptimistic(
    initial,
    (state, next: Todo) => [next, ...state],
  );
  return (
    <form action={async (fd) => {
      addOptimistic({ id: 'temp', title: String(fd.get('title')), done: false } as Todo);
      await addTodo(fd);
    }}>
      <input name="title" /> <button>add</button>
      <ul>{todos.map(t => <li key={t.id}>{t.title}</li>)}</ul>
    </form>
  );
}

The temp row paints immediately. When addTodo finishes and Next revalidates /todos, the server re-renders the list and the temp row is replaced by the real one — same data, same key shape, no flicker.

From a user click to a DB write and back: every hop is typed, server-rendered where possible, with a Server Action closing the write loop.

For session-based auth, Auth.js (NextAuth) v5 is the path of least resistance. Install, configure a provider, and you get an auth() helper you can call from Server Components and Server Actions.

// auth.ts
import NextAuth from 'next-auth';
import Google from 'next-auth/providers/google';
import { PrismaAdapter } from '@auth/prisma-adapter';
import { db } from '@/lib/db';

export const { handlers, auth, signIn, signOut } = NextAuth({
  adapter: PrismaAdapter(db),
  providers: [Google],
});

Add the Auth.js models to schema.prisma, expose its route handler at app/api/auth/[...nextauth]/route.ts, and await auth() works anywhere on the server. For end-to-end ownership of auth you might pick Clerk or build your own, but for most teams Auth.js is enough and free.

Provision a Neon Postgres branch and grab the pooled connection string. In Vercel project settings:

DATABASE_URL=postgresql://user:pw@host/db?sslmode=require
DIRECT_URL=postgresql://user:pw@host/db?sslmode=require   # non-pooled, for migrations

Update schema.prisma:

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DIRECT_URL")
}

In package.json build script: prisma migrate deploy && next build. Push to GitHub, connect the repo in Vercel, click deploy. Neon's branching means every preview deploy can get its own DB branch wired up via the Vercel-Neon integration — your reviewers get a real, isolated environment per PR. That's the whole 2026 full-stack workflow.