Verdict: Better Auth is the default new-SaaS pick; Lucia is now a pattern, not a package
For a new SaaS starter that needs organizations, 2FA, passkeys, rate limiting, and a database-backed TypeScript integration, this guide recommends Better Auth. Those capabilities come from a mix of core concepts and optional plugins, so verify the exact configuration you plan to ship. Lucia v3 remains useful as a session-design reference, but the lucia npm package and its Drizzle adapter are deprecated.
Choose Auth.js v5 when an existing NextAuth-style integration, its provider model, or its documented session strategies matter more than built-in B2B features. The v5 package is still distributed as next-auth@beta as of this August 20, 2026 source check (5.0.0-beta.32), while the next-auth latest dist-tag remains on v4 (4.24.15). Pin the chosen version and document that decision for template users.
Key Takeaways
- New B2B SaaS starter: Better Auth.
- Existing NextAuth/Auth.js boilerplate: stay on Auth.js unless organizations, 2FA, or passkeys are forcing a rebuild.
- Learning or highly custom auth: use the Lucia documentation patterns, not the deprecated Lucia package.
- Drizzle/PostgreSQL query: Auth.js and Better Auth both have active adapter paths; Lucia's Drizzle adapter is deprecated, so a Lucia-style build means owning the schema and session code yourself.
At a glance
| Decision factor | Auth.js v5 | Lucia v3 / Lucia pattern | Better Auth |
|---|---|---|---|
| Best fit in this comparison | Existing NextAuth-style projects and teams that value Auth.js provider/session conventions | Educational or intentionally custom session implementation | New B2B SaaS that needs the documented organization and security plugins |
| Package status checked August 20, 2026 | next-auth@beta exposes v5 (5.0.0-beta.32); next-auth latest is still v4 (4.24.15) | lucia and @lucia-auth/adapter-drizzle are deprecated on npm | better-auth latest is active and non-deprecated (1.7.1) |
| Next.js fit | Strong, especially when a starter already has the v5 auth.ts pattern | Manual integration; you choose route handlers, cookies, and schema | Strong with better-auth/next-js handler helper |
| Drizzle/PostgreSQL fit | Use the official Auth.js Drizzle adapter and database sessions when you need revocation | Build session/user tables directly from the Lucia docs; deprecated adapter should not be the starting point | Use the Better Auth Drizzle adapter and generated schema/migrations |
| B2B organizations | App code you build around Auth.js | Manual | Optional organization plugin |
| 2FA / passkeys | App code or additional packages | Manual | Optional plugins |
| Operational risk | v5 beta distribution and edge/database split config need care | You own every security decision | Newer ecosystem, but deeper built-in feature set |
| StarterPick recommendation | Use if the boilerplate already chose it and the team knows it | Use as a reference, not as a production dependency | Pick first for a new self-hosted SaaS starter |
Why this route is the canonical auth-library comparison
StarterPick has broader guides for authentication setup in Next.js boilerplates, best SaaS boilerplates, and Better Auth boilerplates. This guide is narrower: it answers the Auth.js v5 vs Lucia v3 vs Better Auth decision for SaaS starter authors and buyers.
Use the broader setup guide when you need route protection, signup UX, and billing handoff checklists. Stay here when the question is whether your starter kit should ship Auth.js, Better Auth, or Lucia-style manual sessions.
Choose Better Auth for a new SaaS starter in 2026
Better Auth fits a new self-hosted B2B SaaS when its documented database model and plugins match the product requirements. Its organization, 2FA, passkey, and rate-limit documentation covers common starter-kit needs without proving that every project should enable every plugin.
The practical advantage is not just feature count. A starter-kit buyer expects auth to already include the SaaS pieces that are expensive to retrofit:
- an organization model for teams and workspaces;
- member roles and invitations;
- session and account tables that are generated instead of hand-written in every template;
- server and client helpers that work with Next.js route handlers and React components;
- a Drizzle or Prisma path that matches common starter-kit stacks;
- documented session and plugin behavior that the buyer can inspect and test instead of starting with a blank implementation.
That is the basis for this guide's greenfield recommendation. It is a conditional editorial decision, not a vendor-proven universal ranking. Confirm the adapter, plugin schemas, migration output, session behavior, and upgrade path against the starter's actual code before adopting it.
Choose Auth.js v5 when OAuth familiarity matters more than B2B depth
Auth.js remains a familiar choice for many Next.js teams. Its official documentation covers v5 migration, server-side auth() usage, session strategies, edge-compatibility trade-offs, and adapters including Drizzle and Prisma.
A typical v5 setup still feels familiar to NextAuth users:
// auth.ts
import NextAuth from "next-auth";
import GitHub from "next-auth/providers/github";
import { DrizzleAdapter } from "@auth/drizzle-adapter";
import { db } from "@/db";
export const { handlers, auth, signIn, signOut } = NextAuth({
adapter: DrizzleAdapter(db),
providers: [GitHub],
session: { strategy: "database" },
});
// app/api/auth/[...nextauth]/route.ts
export const { GET, POST } = handlers;
The catch for a StarterPick-style template is scope. Auth.js handles authentication, providers, callbacks, cookies, and sessions. It does not give you a full B2B SaaS layer. If your boilerplate promises teams, invitations, tenant roles, admin screens, and 2FA, you either build those modules around Auth.js or combine it with another identity/organization product.
The second catch is version posture. The v5 docs are real and the package exists, but npm still exposes v5 through the beta dist-tag (5.0.0-beta.32 on August 20, 2026) while the latest next-auth tag remains v4 (4.24.15). For a team already committed to Auth.js, that is manageable. For a commercial starter kit whose buyers expect boring dependencies, it is a reason to document your version choice clearly.
Treat Lucia v3 as a session blueprint, not a dependency choice
Lucia is the most misunderstood option in this comparison. The current Lucia site positions itself as an open-source resource on implementing authentication with JavaScript, and the lucia package is marked deprecated on npm. The same is true for the Lucia Drizzle adapter.
That does not make Lucia irrelevant. It means the right lesson changed. Lucia's session pattern is still excellent if you want to understand or implement auth yourself:
import { sha256 } from "@oslojs/crypto/sha2";
import { encodeBase32LowerCaseNoPadding, encodeHexLowerCase } from "@oslojs/encoding";
export function generateSessionToken() {
const bytes = new Uint8Array(20);
crypto.getRandomValues(bytes);
return encodeBase32LowerCaseNoPadding(bytes);
}
export async function hashSessionToken(token: string) {
return encodeHexLowerCase(sha256(new TextEncoder().encode(token)));
}
For a small internal tool or a team with deep security experience, Lucia-style manual sessions can be the most transparent approach. For a SaaS starter that other founders will clone, it is usually a poor default because every important behavior becomes product code: token entropy, cookie flags, session renewal, account linking, password reset, OAuth state checks, CSRF protection, and user/session cleanup.
The clearest recommendation: do not start a new 2026 boilerplate by adding lucia or @lucia-auth/adapter-drizzle. Use Lucia's docs to understand sessions, then choose Better Auth or Auth.js unless you intentionally want to own the whole auth implementation.
Framework and runtime matrix: Drizzle and PostgreSQL implications
The GSC query cluster for this guide includes Lucia, Better Auth, and a Lucia Drizzle/PostgreSQL adapter example query. The adapter decision is where the comparison becomes concrete.
| Stack need | Auth.js v5 | Lucia pattern | Better Auth |
|---|---|---|---|
| Drizzle adapter | Official @auth/drizzle-adapter package | Deprecated Lucia adapter; build tables manually | Official Better Auth Drizzle adapter docs |
| PostgreSQL sessions | Supported through database sessions and adapter tables | You design the tables, indexes, expiry cleanup, and token hashing | Generated schema/migration path with core user, session, account, and verification tables |
| Edge middleware | Edge reads often push you toward JWT/split-config patterns because database adapters may not be edge-compatible | You decide whether edge reads use signed state, database calls, or route-level checks | Usually keep auth checks in route/server contexts unless your adapter/runtime choice is edge-safe |
| Migration burden | Depends on the current NextAuth/Auth.js version, callbacks, adapter, and session strategy | App owns every auth table and behavior | Smaller for a matching greenfield schema; material when migrating existing users and sessions |
For StarterPick readers building on Neon/Postgres and Drizzle, this guide recommends Better Auth when its generated schema and plugins match the product requirements. Auth.js remains viable when its provider and session model fits an existing project. Lucia-style Drizzle/PostgreSQL is now a custom-auth project, not an adapter shortcut.
Session security: where teams underestimate the work
Session security is the largest ownership difference in the Lucia-style path. A framework can supply documented defaults and helpers, but package choice alone does not make an implementation secure.
Auth.js documents JWT and database session strategies. JWT sessions avoid a database lookup for each session read but require a deliberate revocation plan. Database sessions support server-side invalidation while adding database and adapter/runtime constraints. Read the edge-compatibility guidance before promising middleware-level database-session checks in a template.
Better Auth centers the schema and session model in the framework. Its database docs cover core schema, adapters, migrations, hooks, and plugin schemas. Its plugin system can extend auth behavior without forcing every starter author to invent an internal auth framework.
Lucia-style sessions make the application responsible for token hashing, cookie settings, expiry, renewal, origin validation where appropriate, and cleanup. That can be a deliberate choice for a team prepared to review and test each control. It is a poor default when a starter-kit buyer will assume those controls are already maintained.
Migration cost by starting point
Auth.js to Better Auth
Plan for a real migration, not a package swap. You will add Better Auth's route handler and client, create its core tables, migrate accounts/sessions/users where practical, update middleware and server components, and retest every protected route. If your product has teams, you will also map existing organization tables into Better Auth's organization plugin or keep your current organization model.
Lucia package to Better Auth
Do not migrate by preserving the deprecated Lucia package. Extract the durable concepts: user IDs, account records, session expiry policy, and cookie names. Then move to Better Auth's generated schema or to your own audited manual-session module. Expect session invalidation unless you deliberately preserve token hashing and table semantics.
Better Auth to managed auth
Better Auth keeps user/session data in your database, which is good for ownership. A move to Clerk, WorkOS AuthKit, or another managed service still means user-ID mapping, webhook replacement, session-check rewrites, and account-import testing. Choose managed auth up front if you know you want to offload maintenance rather than self-host.
Recommended starter-kit defaults
| Starter type | Recommended auth default | Why |
|---|---|---|
| Solo founder SaaS with teams later | Better Auth | Starts with the organization/2FA/session pieces you will need before selling to teams. |
| OAuth-first consumer app | Auth.js v5 or Better Auth | Auth.js is familiar; Better Auth is deeper if you also want email/password and passkeys. |
| Enterprise B2B starter | Better Auth plus a later WorkOS/SSO layer if needed | Better Auth covers app auth; enterprise SSO/provisioning can be added when deals require it. |
| Educational/auth-from-scratch template | Lucia pattern | Useful if the value proposition is learning auth internals, not shipping quickest. |
| Existing mature NextAuth app | Stay on Auth.js until a specific missing feature justifies migration | Migration risk usually beats theoretical library preference. |
Source-backed caveats
- Version and package-registry signals were checked on August 20, 2026. They are useful maintenance signals, not quality rankings.
next-authstill exposes v5 through the5.0.0-beta.32beta tag while latest is4.24.15;better-authlatest was active at1.7.1; and theluciaand@lucia-auth/adapter-drizzlepackages remain deprecated in npm metadata. - Documentation can move faster than starter kits. Before buying a boilerplate, inspect the actual repository for its auth package version, migration files, route protection, session strategy, and invite/organization implementation.
- Auth libraries do not automatically solve authorization. You still need product-level checks for tenant membership, billing state, admin roles, and API access.
- Prices and plan names change. This guide focuses on self-hosted library fit rather than managed-auth pricing, so verify any Clerk, WorkOS, or hosted-provider pricing on the vendor site before committing.
Related guides
- Authentication setup in Next.js boilerplates for route protection, billing handoffs, and implementation checklists.
- Best boilerplates using Better Auth for starters that already pick Better Auth.
- Better Auth + Polar + Drizzle SaaS starter guide for a modern self-hosted stack around auth, billing, and Postgres.
- Best SaaS boilerplates 2026 for the full StarterPick landscape.
- Best Next.js boilerplates 2026 for App Router starter-kit comparisons.
Source notes
Sources checked August 20, 2026: Auth.js v5 migration, session strategy, and edge compatibility docs; npm registry pages for next-auth, @auth/drizzle-adapter, and @auth/prisma-adapter; Lucia docs and npm deprecation notices for lucia and @lucia-auth/adapter-drizzle; Better Auth installation, database, organization, and 2FA docs; npm registry page for better-auth.
Methodology
This refresh prioritizes the query cluster around lucia auth vs better auth, lucia vs better auth, better auth vs lucia 2026, and Drizzle/PostgreSQL adapter searches. The scoring lens is practical SaaS starter fit: maintenance status, Next.js integration, database adapter path, B2B feature depth, session-security defaults, migration cost, and whether the choice helps or hurts a boilerplate buyer trying to ship a production app.