Database-backed authentication
Persisting Auth.js users, linked provider accounts, sessions, and verification records in Neon PostgreSQL.
Auth.js · Const
NeonAdapter connects Auth.js to Neon PostgreSQL through a Neon serverless Pool. Pass the Pool to Auth.js as its database adapter.
NeonAdapter connects Auth.js to a Neon PostgreSQL database through a serverless Pool. Pass the Pool to the adapter in the Auth.js configuration so Auth.js can persist users, accounts, sessions, and verification data using its expected schema.
NeonAdapter(client)| Name | Type | Description |
|---|---|---|
client | Pool | Neon serverless PostgreSQL connection pool supplied to the adapter factory. |
Adapter
@auth/neon-adapter package.@neondatabase/serverless as the database client.adapter property.import NextAuth from "next-auth"
import NeonAdapter from "@auth/neon-adapter"
import { Pool } from "@neondatabase/serverless"
export const { handlers, auth, signIn, signOut } = NextAuth(() => {
const pool = new Pool({ connectionString: process.env.DATABASE_URL })
return {
adapter: NeonAdapter(pool),
providers: [],
}
})Creates a Neon connection pool inside the request-time Auth.js configuration and passes it to the adapter.
Persisting Auth.js users, linked provider accounts, sessions, and verification records in Neon PostgreSQL.
Running Auth.js with Neon PostgreSQL in a serverless or edge-oriented deployment.
Using the standard Auth.js database model with a Neon-hosted PostgreSQL backend.
NeonAdapter is the official PostgreSQL adapter for Auth.js and accepts a Neon serverless Pool. It returns an Auth.js Adapter that supplies the database operations required by authentication.
Follow-up: What must the database provide? It must contain the tables and columns described by the adapter's SQL schema so those operations can persist Auth.js data.
The adapter factory is called with a Pool: NeonAdapter(pool). The API reference specifies that its parameter is a Pool and its return value is an Adapter.
Follow-up: Why use the Neon serverless Pool? It is the client type shown by the integration documentation for connecting Auth.js to Neon PostgreSQL in serverless environments.
In the documented Next.js configuration, the Pool is constructed inside the function supplied to NextAuth, not at module scope. This keeps connection creation within the request-time handler pattern shown by the page.
Follow-up: Would the same placement rule necessarily apply to every framework example? No: the page's Express example constructs the Pool at module scope, so follow the placement shown for the target framework.
PoolAdapter@auth/neon-adapter@neondatabase/serverlessNextAuth