DEV Community: Golam Rabbani

Setting Up Better-Auth in Next.js with Kysely + Prisma Schema

Golam Rabbani — Fri, 14 Nov 2025 12:12:40 +0000

In this post I’ll show how I integrated Better-Auth into a Next.js App Router project that uses:

Prisma only for schema management
Kysely as the type-safe query builder
Any SQL database (I am using Neon Postgres, but you can use others)

📌 Before you continue:

This guide builds on top of the Prisma + Kysely setup from my previous blog.

If you haven’t done that setup yet, this guide will not work as-is. please read it first -
👉 Using Prisma for Schema and Kysely for Queries in a Next.js App

1. Install Better-Auth Packages

I prefer pnpm, so I’ll use it. You can replace it with npm/yarn.

Install only the packages we need:

pnpm add better-auth better-auth/next-js better-auth/react

This is the full Better-Auth stack for Next.js App Router + React hooks.

2. (Optional) Database Setup with Kysely + Prisma

My setup uses:

Prisma → schema
prisma-kysely → generate DB types
Kysely → actual querying

The full database setup (scripts, configs, generators, etc.) is explained in my previous blog.

Here, we only focus on the schema required by Better-Auth.

3. Schema Required by Better-Auth

Better-Auth depends on the following models:

User
Session
Account
Verification

Paste this exact schema in your prisma/schema.prisma:

model User {
  id            String    @id @db.Text
  email         String    @unique @db.Text
  name          String    @db.Text
  image         String?   @default("") @db.Text
  emailVerified Boolean   @default(false)
  createdAt     DateTime  @default(now()) @db.Timestamptz
  updatedAt     DateTime  @updatedAt @db.Timestamptz

  sessions      Session[]
  accounts      Account[]

  @@map("user")
}

model Session {
  id        String   @id @db.Text
  expiresAt DateTime @db.Timestamptz
  token     String   @unique @db.Text
  createdAt DateTime @default(now()) @db.Timestamptz
  updatedAt DateTime @updatedAt @db.Timestamptz
  ipAddress String?  @db.Text
  userAgent String?  @db.Text
  userId    String   @db.Text

  user User @relation(fields: [userId], references: [id], onDelete: Cascade)

  @@map("session")
}

model Account {
  id                    String    @id @db.Text
  accountId             String    @db.Text
  providerId            String    @db.Text
  userId                String    @db.Text
  accessToken           String?   @db.Text
  refreshToken          String?   @db.Text
  idToken               String?   @db.Text
  accessTokenExpiresAt  DateTime? @db.Timestamptz
  refreshTokenExpiresAt DateTime? @db.Timestamptz
  scope                 String?   @db.Text
  password              String?   @db.Text
  createdAt             DateTime  @default(now()) @db.Timestamptz
  updatedAt             DateTime  @updatedAt @db.Timestamptz

  user User @relation(fields: [userId], references: [id], onDelete: Cascade)

  @@map("account")
}

model Verification {
  id         String   @id @db.Text
  identifier String   @db.Text
  value      String   @db.Text
  expiresAt  DateTime @db.Timestamptz
  createdAt  DateTime @default(now()) @db.Timestamptz
  updatedAt  DateTime @default(now()) @updatedAt @db.Timestamptz

  @@map("verification")
}

Now generate types and push schema:

pnpm db:generate
pnpm db:push

db:generate → Converts Prisma models into Kysely types
db:push → Updates your actual database

These generated types are required for Kysely to be fully type-safe.

4. Kysely Client

Below is the minimal Kysely client used in this blog.

I am using Neon, but you can use any provider by switching the dialect:

// server/db/index.ts
import { Kysely } from 'kysely'
import { NeonDialect } from 'kysely-neon'
import { neon } from '@neondatabase/serverless'
import type { DB } from '@/db/types/kysely'

export const db = new Kysely<DB>({
  dialect: new NeonDialect({
    neon: neon(process.env.DATABASE_URL!),
  }),
})

5. Environment Variables (.env)

Create/update your .env:

DATABASE_URL="postgresql://user:password@host:5432/dbname?sslmode=require"

BETTER_AUTH_SECRET="paste-generated-secret-here"

GOOGLE_CLIENT_ID="your-google-client-id"
GOOGLE_CLIENT_SECRET="your-google-client-secret"

GITHUB_CLIENT_ID="your-github-client-id"
GITHUB_CLIENT_SECRET="your-github-client-secret"

Generate `BETTER_AUTH_SECRET`

openssl rand -base64 32

Paste it into .env.

6. Better-Auth Setup

6.1. Server Auth (`lib/auth.ts`)

// lib/auth.ts
import { betterAuth } from 'better-auth'
import { db } from '@/server/db'

const secret = process.env.BETTER_AUTH_SECRET
if (!secret) throw new Error('BETTER_AUTH_SECRET is not configured')

export const auth = betterAuth({
  secret,
  database: {
    db,
    type: 'postgres',
  },
  socialProviders: {
    google: {
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
    },
    github: {
      clientId: process.env.GITHUB_CLIENT_ID!,
      clientSecret: process.env.GITHUB_CLIENT_SECRET!,
    },
  },
})

export type Session = typeof auth.$Infer.Session

6.2. Next.js API Route

// app/api/auth/[...all]/route.ts
import { toNextJsHandler } from 'better-auth/next-js'
import { auth } from '@/lib/auth'

export const { GET, POST } = toNextJsHandler(auth)

6.3. Client Helpers

// lib/auth-client.ts
import { createAuthClient } from 'better-auth/react'

export const authClient = createAuthClient({
  basePath: '/api/auth',
})

export const { signIn, signOut, signUp, useSession } = authClient

7. Implementing the Auth Flow

Below are simple examples that help you understand how to actually use Better-Auth in a basic Next.js app.

7.1. Sign-In Form (Google + GitHub)

// components/login-form.tsx
'use client'

import { useState, useTransition } from 'react'
import { signIn } from '@/lib/auth-client'

export function LoginForm() {
  const [pending, startTransition] = useTransition()
  const [error, setError] = useState<string | null>(null)

  const handleSignIn = (provider: 'google' | 'github') => {
    startTransition(async () => {
      const { error } = await signIn.social({
        provider,
        callbackURL: '/app',
      })

      if (error) setError(error.message)
    })
  }

  return (
    <div className="space-y-4">
      <button disabled={pending} onClick={() => handleSignIn('google')} className="w-full rounded border px-3 py-2">
        Continue with Google
      </button>

      <button disabled={pending} onClick={() => handleSignIn('github')} className="w-full rounded border px-3 py-2">
        Continue with GitHub
      </button>

      {error && <p className="text-sm text-red-500">{error}</p>}
    </div>
  )
}

7.2. Simple Sign-Out Example

// components/signout-button.tsx
'use client'

import { useTransition } from 'react'
import { useRouter } from 'next/navigation'
import { signOut } from '@/lib/auth-client'

export function SignOutButton() {
  const [pending, startTransition] = useTransition()
  const router = useRouter()

  const handleSignOut = () => {
    startTransition(async () => {
      await signOut({
        fetchOptions: {
          onSuccess: () => router.push('/signin'),
        },
      })
    })
  }

  return (
    <button onClick={handleSignOut} disabled={pending} className="rounded border px-3 py-1">
      {pending ? 'Signing out...' : 'Sign out'}
    </button>
  )
}

7.3. Protecting a Server Component Route

// app/(app)/layout.tsx
import { headers } from 'next/headers'
import { redirect } from 'next/navigation'
import { auth } from '@/lib/auth'
import { SignOutButton } from '@/components/signout-button'

export default async function AppLayout({ children }) {
  const session = await auth.api.getSession({ headers: await headers() })

  if (!session) redirect('/signin')

  return (
    <div className="p-4 space-y-6">
      <SignOutButton />
      {children}
    </div>
  )
}

7.4. Server Action with Auth Guard

// server/actions/get-user-data.ts
'use server'

import { headers } from 'next/headers'
import { auth } from '@/lib/auth'

export async function getUserData() {
  const session = await auth.api.getSession({ headers: await headers() })

  if (!session) throw new Error('Unauthorized')

  // You Server codes/ DB fetches


  // return your response
}

7.5. Securing an API Route

// app/api/profile/route.ts
import { headers } from 'next/headers'
import { NextResponse } from 'next/server'
import { auth } from '@/lib/auth'

export async function GET() {
  const session = await auth.api.getSession({ headers: await headers() })

  if (!session) return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })

  return NextResponse.json({
    email: session.user.email,
  })
}

8. Extensions

Better-Auth supports:

Password-based auth
Passkeys
Email login
Multi-factor authentication
Webhooks
More providers

All extensions plug into the same config shown earlier.

See the official documentation for details.

9. Folder Structure Used in This Blog

Here’s how the complete Better-Auth + Kysely + Prisma setup looks in a clean and simple structure:

📦 my-next-app
├── 📁 app
│   ├── 📁 api
│   │   └── 📁 auth
│   │       └── [...all]
│   │           └── route.ts
│   ├── 📁 (auth)
│   │   └── 📁 signin
│   │       └── page.tsx
│   └── 📁 (app)
│       ├── layout.tsx
│       └── 📁 app
│           └── page.tsx
│
├── 📁 components
│   ├── login-form.tsx
│   └── signout-button.tsx
│
├── 📁 db
│   ├── schema.prisma
│   └── 📁 types
│       └── kysely.d.ts
│
├── 📁 lib
│   ├── auth.ts
│   └── auth-client.ts
│
├── 📁 server
│   ├── 📁 db
│   │   └── index.ts
│   └── 📁 actions
│       └── get-user-email.ts
│
├── .env
├── package.json
├── pnpm-lock.yaml
└── tsconfig.json

Using Prisma for Schema and Kysely for Queries in a Next.js App

Golam Rabbani — Tue, 04 Nov 2025 13:12:53 +0000

When I first started using Prisma, I loved how easy it made database work - migrations, schema changes, Prisma Studio, all just worked.

But once I started deploying more apps on Vercel and serverless environments, I noticed something: Prisma Client felt a bit heavy.

Every time I deployed, my bundle size grew. And I didn't really need the full ORM - I just wanted a way to manage my schema and write type-safe SQL queries.

That's when I found a good balance:
👉 Use Prisma only for schema management, and Kysely for queries.

This setup has been super clean for me in my Next.js projects - and in this post, I'll show you exactly how to do it.

Why Prisma + Kysely Combo

I like to think of it like this:

Prisma is my database architect. It manages the schema, migrations, and gives me tools like prisma studio.
Kysely is my query builder. It lets me write SQL in TypeScript with full type safety and a smaller runtime size.
The prisma-kysely generator connects both worlds - it generates Kysely types directly from your Prisma schema.

So, Prisma stays for the dev experience.

Kysely takes over at runtime.

No Prisma Client in production - just lean, type-safe SQL.

Step 1: Install Dependencies

Let's start by adding the right packages.

I'm using pnpm here, but you can also use npm or yarn.
I just prefer pnpm because it's faster and saves disk space.

pnpm add kysely kysely-neon @neondatabase/serverless
pnpm add -D prisma prisma-kysely

Notice that prisma is a dev dependency, because we'll use it only for schema and code generation - not at runtime.

Step 2: Write Your Prisma Schema

Here's a small and simple schema with User and Post models.

// db/schema.prisma

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

generator kysely {
  provider = "prisma-kysely"
  output   = "./types"
}

model User {
  id    Int    @id @default(autoincrement())
  name  String
  email String  @unique
  posts Post[]
}
model Post {
  id        Int      @id @default(autoincrement())
  title     String
  content   String?
  authorId  Int
  createdAt DateTime @default(now())
  author    User     @relation(fields: [authorId], references: [id])
}

Now run the following commands to sync the schema and generate Kysely types:

pnpm prisma generate
pnpm prisma db push

This will create a file like db/types/kysely.d.ts which includes all your types.

Add helpful scripts to your package.json

It's a good idea to add a few Prisma scripts for convenience:

{
  "scripts": {
    "db:push": "prisma db push",
    "db:generate": "prisma generate",
    "db:studio": "prisma studio"
  }
}

Now whenever you change something in the Prisma schema, just run:

# To generate the types
pnpm db:generate
# To push to the remote DB
pnpm db:push

This will update both the database and the Kysely types automatically

Step 3: Choose a Kysely Dialect

Kysely doesn't connect to your database directly - it uses a dialect.

You can think of it as the "bridge" that knows how to talk to your database.

Some dialects are official (like PostgreSQL, MySQL, SQLite), and others are community-built (like Neon, PlanetScale, Turso, etc.).

Let's see two popular options 👇

🟢 Option 1: Neon (Serverless) Setup

If you're deploying to Vercel or another serverless platform, Neon is great.

It uses an HTTP-based connection, so you don't need to maintain a persistent database connection.

// db/index.ts
import { Kysely } from 'kysely'
import { NeonDialect } from 'kysely-neon'
import { neon } from '@neondatabase/serverless'
import type { DB } from './types/kysely'

const db = new Kysely<DB>({
  dialect: new NeonDialect({
    neon: neon(process.env.DATABASE_URL!),
  }),
})

export default db

However, keep this in mind:

kysely-neon runs over HTTP, which means no transaction queries or session-based operations.
It's perfect for simple CRUD or read-heavy apps, but not for complex transactions.

Also note:

If you use WebSockets with Neon, you don't need kysely-neon.
You can just use Neon's Pool with Kysely's built-in Postgres dialect.

🟣 Option 2: Postgres (pg) Setup

If you're running a traditional Node.js or edge-compatible backend, the official pg driver is still the best.

It supports full transactions, connection pooling, and prepared statements.

// db/index.ts
import { Kysely, PostgresDialect } from 'kysely'
import { Pool } from 'pg'
import type { DB } from './types/kysely'

const db = new Kysely<DB>({
  dialect: new PostgresDialect({
    pool: new Pool({
      connectionString: process.env.DATABASE_URL,
    }),
  }),
})

export default db

Dialect	Connection Type	Supports Transactions	Best For
kysely-neon	HTTP (Serverless)	❌ No	Vercel, Netlify, Cloudflare
pg	TCP (Persistent)	✅ Yes	Node.js servers or edge backends

So, in short:

Use kysely-neon for serverless setups, and pg when you need full database features like transactions.

Step 4: Use Kysely in a Next.js Server Component

Let's try a small example - fetching all users in a server component.

// app/users/page.tsx
import db from '@/db'

export default async function UsersPage() {
  const users = await db
    .selectFrom('user')
    .select(['id', 'name', 'email'])
    .orderBy('id')
    .execute()

  return (
    <div>
      <h1>Users</h1>
      <ul>
        {users.map(u => (
          <li key={u.id}>{u.name} ({u.email})</li>
        ))}
      </ul>
    </div>
  )
}

This query is completely type-safe.

If you type the wrong table or column name, TypeScript will catch it immediately - because Kysely's types come directly from your Prisma schema.

Step 5: Typical Workflow Recap

Update models in db/schema.prisma.
Run pnpm db:generate and pnpm db:push to generate the types and sync changes.
Use the db instance in your Next.js server components, API routes, or actions.
Validate inputs with Zod or any schema library before inserting.

Example Folder Structure

Here's how the full setup looks in a clean folder tree:

📦 my-next-app
├── 📁 app
│   └── 📁 users
│       └── page.tsx
├── 📁 db
│   ├── schema.prisma
│   ├── index.ts
│   └── 📁 types
│       └── kysely.d.ts
├── 📁 node_modules
├── .env
├── package.json
├── pnpm-lock.yaml
└── tsconfig.json

Final Thoughts

This setup has worked really well for me in my Next.js apps.

I still get all of Prisma's nice tools - schema, migrations, Prisma Studio - but without pulling Prisma Client into production.

Kysely makes my queries simple, type-safe, and fast.

And Prisma keeps my database organized.

If you're using Postgres and want to keep your app lean, type-safe, and serverless-friendly, try this approach once.

It's clean, easy to maintain, and feels great to work with.

✍️ Quick summary

Prisma = schema & migrations
Kysely = type-safe SQL
Together = clean, fast, serverless-ready setup