Modern Next.js Stack Tradeoffs: ORM, Auth, and State

Core content#

This card comes out of a Grok conversation about picking a modern Next.js / TypeScript stack, with the comparisons centering on three pairs:

Drizzle vs Prisma
Arctic vs NextAuth / Auth.js
Jotai vs Redux

The most valuable thing about this discussion isn’t that it hands you a single “correct answer” — it’s that it pulls apart three common tradeoffs:

The database access layer: lighter and closer to SQL, or a more mature, more abstracted ORM experience
The auth approach: a lower-level, more controllable OAuth composition, or a more complete auth framework
Frontend state management: lighter atomic state, or a more opinionated global-state solution with a larger ecosystem

If I compress it down to a single conclusion up front:

For most new Next.js projects in 2026, the overall lean is Drizzle + (Arctic / Auth.js depending on complexity) + Jotai. But the moment a team leans harder on a mature toolchain, low SQL cognitive overhead, complete auth capabilities, or strict state transitions, Prisma / Auth.js / Redux Toolkit still have a legitimate place.

Key points#

1. Drizzle vs Prisma: at heart it’s a tradeoff between a “thin, SQL-first layer” and a “mature abstraction layer”#

In this conversation, the overall read on Drizzle is:

Closer to the database
More lightweight
More Serverless / Edge friendly
A shorter query path
A better fit for new projects that chase performance and a sense of control

The read on Prisma, by contrast, is:

More mature
More complete tooling like Studio / Migrate
Easier for a team to pick up
A better fit for teams that don’t want to get deep into SQL

Drizzle’s strengths cluster around these points#

SQL-first / Code-first: you describe the schema in TypeScript, but the mindset still feels more like writing SQL
Almost no extra query-engine overhead: closer to a thin wrapper than a heavy abstraction
Smaller bundle, shorter cold starts: especially well-suited to Vercel Serverless, Cloudflare Workers, the Edge Runtime
Performance closer to raw SQL: a clearer advantage in complex queries, index utilization, and scenarios that are more sensitive to the quality of the generated SQL
A stronger sense of control: when you need to hand-write raw SQL or fine-tune a query, things are less likely to “fight” you

Prisma’s strengths cluster around these points#

A mature developer experience: the Schema, Client, Studio, Migrate workflow feels very smooth to a lot of teams
A gentler learning curve: especially friendlier to developers who aren’t comfortable with SQL but are used to a high-level ORM
A more stable ecosystem: more documentation, more community conventions, more accumulated history from past projects
More consistency in team collaboration: in multi-person, standardized development, it’s often easier to establish unified constraints

The one judgment from this conversation most worth remembering#

Drizzle is more like “the default choice for modern deployment environments and performance-sensitive scenarios,” while Prisma is more like “the safe choice for a mature team toolchain and an abstracted experience.”

2. Why Drizzle is a better fit for Serverless#

The second half of the conversation has a follow-up that mainly explains:

Why people say Drizzle is a better fit for Serverless
What Serverless / Vercel Serverless actually means
Why bundle size and cold starts directly affect the real-world experience of an ORM

The core understanding is:

Serverless isn’t “no servers” — it’s “functions that start on demand”#

Typical scenarios include:

Next.js API Routes
Vercel Serverless Functions
Vercel Edge Functions
Cloudflare Workers
AWS Lambda

In these environments, function instances get spun up frequently. Every time one spins up, there’s:

Loading the code bundle
Initializing dependencies
Establishing a database connection or preparing the driver
Executing the request

If the dependencies are heavy:

Cold starts are slower
Users are more likely to feel first-paint / first-request latency
And on platforms that bill by execution time, costs go up too

Drizzle’s advantage here isn’t “more features” — it’s “less overhead”#

The logic this discussion lays out is clear:

Drizzle itself is very light
It doesn’t carry that heavy extra query-engine overhead
It’s a better fit for edge environments
It’s friendlier on cold starts and memory footprint

So it’s a better fit for:

High-concurrency APIs
Global edge deployment
Cold-start-sensitive SaaS / app backends
Projects centered on Vercel / Cloudflare / Supabase Edge as their core deployment platform

What you should actually remember here isn’t “Drizzle is always better,” but:

Once a deployment environment is especially sensitive to bundle size, cold starts, and edge compatibility, the weight of your ORM shifts from being an “engineering detail” to being a “product experience problem.”

3. Why Drizzle is generally considered to query faster#

The explanation in the conversation is pretty blunt:

Drizzle is a thinner layer
Even though Prisma has gotten noticeably lighter, it’s still a higher-level abstraction
The thicker the abstraction layer, the longer the query path, and the more uncontrollable factors there are in the generated SQL

The key point here isn’t “Prisma is slow,” but:

Simple CRUD: the gap between the two is usually small
Complex queries / complex joins / queries sensitive to SQL quality: Drizzle finds it easier to stay close to the database’s native capabilities
Mixing in raw SQL: Drizzle is more natural

So the more accurate conclusion should be:

Drizzle’s performance advantage mainly comes from “one fewer layer of abstraction” and “staying closer to database semantics” — it’s not magic acceleration.

4. Arctic vs Auth.js: a lightweight OAuth tool vs a complete auth framework#

In this conversation, Arctic’s positioning is clear:

It’s a lightweight OAuth library
It’s not a complete, all-in-one auth framework
It’s a better fit when you want to control the session, database, and auth flow yourself

And Auth.js (formerly NextAuth) is positioned as:

A complete auth framework
More mainstream within the Next.js ecosystem
A good fit for quickly supporting common needs like OAuth, Session, and a Database Adapter

When to lean toward Arctic#

The project is relatively small
You want to retain more control
You don’t like “everything-and-the-kitchen-sink” auth frameworks
You already have your own Session / Database setup
You care more about a clean, lightweight, composable system

When to lean toward Auth.js#

You need to ship fast
You need multiple OAuth providers
You need fairly complete auth capabilities
You don’t want to re-stitch the Session / Adapter / persistence logic yourself
You want to be on the mainstream side of the Next.js ecosystem

This kind of judgment looks a lot like the Drizzle / Prisma one above:

Arctic is more like composable little parts; Auth.js is more like a complete toolbox.

5. Jotai vs Redux: state management shifting from “convention-first” to “lightweight-first”#

The overall lean of this conversation is:

By 2026, Redux is no longer the default choice
For a lot of new React / Next.js projects, lightweight options like Jotai / Zustand feel more natural

Jotai’s strengths#

A lighter, atomic mental model
Concise syntax
A more natural transition between local state and globally shared state
Less boilerplate
A better fit for small-to-medium projects or component-driven modern React development

Redux Toolkit’s strengths#

Strong conventions
A very mature DevTools ecosystem
Easier to unify the management of complex business state across a team
A good fit for large enterprise applications, complex async flows, and strict state-transition scenarios

6. What “boilerplate” actually means here#

The conversation specifically explains the boilerplate in Jotai vs Redux.

The understanding of this word most worth keeping is:

It’s not the code the business itself needs — it’s “the big pile of boilerplate structure you’re forced to write first just to use this framework.”

In the Redux world, this usually means:

action
reducer / slice
store
the dispatch flow
selector
all kinds of fixed organizational patterns

Redux Toolkit has already taken a lot of the pain out of old-school Redux, but in many lightweight projects these structures still feel on the heavy side.

And Jotai’s appeal is exactly that:

State definitions are usually closer to a plain declaration
The business code and the state code sit closer together
There’s noticeably less extra code written just to “make the state-management framework work”

So the real issue here isn’t “less code is more advanced,” but:

If state complexity isn’t high, there’s no need to introduce a whole set of heavy constraints prematurely.

Current understanding / conclusion#

This conversation can ultimately be compressed into a very practical decision framework:

When leaning toward a modern, lightweight combination#

Favor:

Drizzle: deploying on Serverless / Edge, chasing performance and lightness, willing to get close to SQL
Arctic: want to retain maximum control, composing the Session / DB / Auth flow yourself
Jotai: low-to-medium state complexity, want to cut boilerplate and cognitive overhead

This combination is a better fit for:

New projects
Personal projects
Small-team products
Modern web apps that chase being light, fast, and controllable

When leaning toward a mature, safe combination#