Databases & ORMs in Next.js

Every non-trivial application needs durable state. In Next.js, the question is not just which database or ORM to choose, but where data access runs in the first place. With React Server Components and the App Router, the default answer is on the server: the component renders where the database connection lives, and the browser receives only the final HTML or JSON payload.

Next.js does not prescribe a specific ORM or driver. It gives you a runtime environment where Server Components can be async, where Server Actions can mutate data securely, and where caching and revalidation are first-class primitives. The database layer is still your choice: Prisma for schema-first ergonomics, Drizzle for type-safe SQL, TypeORM for existing Node.js projects, or raw drivers when you need minimal overhead.

This guide is about integrating databases and ORMs into Next.js at production scale. You will learn how to query inside Server Components, configure Prisma and Drizzle, run mutations through Server Actions, handle connection pooling in serverless environments, choose edge-compatible drivers, and cache query results without serving stale data. The goal is to keep connections healthy, types safe, and secrets off the client.

In the App Router, every page component can be asynchronous. That means a Server Component can fetch data directly from the database without a separate REST or GraphQL layer. The client never sees the connection string, the query string, or the raw ORM client. It receives only the rendered result.

Server Components run on the server during rendering, so they are the ideal place for database reads. They can also be nested: a layout can fetch a user session, a page can fetch a list of posts, and each post card can be a child Server Component that receives the data as props. Because each component has access to the full request context, you can read cookies, validate headers, and pass tenant identifiers straight into the query.

The server-first pattern removes the need for client-side data fetching libraries for most read-only pages. Tools like React Query or SWR are still useful for interactive client components, such as live dashboards and infinite scroll, but they should call server-side route handlers or Server Actions, never the database directly.

Prisma is a schema-first ORM with a powerful type generator. It gives you a declarative data model, a migration system, and a type-safe query engine. For Next.js projects, the main workflow is: define a schema, run migrations, generate the client, and use a singleton instance to avoid connection exhaustion during development.

Start with the schema. Keep it in prisma/schema.prisma and point the database URL to an environment variable. A good schema defines explicit relations, indexes, and native types, so that the database enforces the same constraints the TypeScript types imply.

The Prisma client must be a singleton. In development, Next.js hot reloads modules and can create new client instances on every request. A module-scoped variable guarded by the global object prevents connection leaks.

Use the singleton in Server Components and Server Actions. Reads are straightforward, and the returned types flow into the rest of the component tree. For mutations, wrap writes in a Server Action, validate input with a schema library, and return structured results so the UI can show clear error states.

Migrations are run from the CLI. In production, you typically run prisma migrate deploy as part of your build command or deployment pipeline, not inside the application code. Keep the migrate command separate from the server start so that schema changes do not block new pods from serving traffic.

Drizzle is a type-safe SQL toolkit that stays close to the database. It is often described as an ORM, but it behaves more like a SQL builder: you define schemas with TypeScript, write queries that look like SQL, and still get full type inference. It is smaller than Prisma and tends to be more edge-friendly because it uses lightweight database drivers rather than a native binary engine.

A typical Drizzle setup with PostgreSQL uses the drizzle-orm core and drizzle-kit for migrations, plus the @neondatabase/serverless or pg driver. The schema file is pure TypeScript, which makes it easy to colocate with your application code.

Initialize the connection once and reuse it. Drizzle uses a database connection object, so the same singleton pattern applies. With a serverless HTTP driver like Neon, the connection is stateless and edge-compatible; with a TCP driver like pg, you need to manage pooling and connection limits.

Queries in Server Components look like SQL but are fully typed. You can select, filter, order, and join with explicit relations. The query builder returns plain objects, so they serialize over the component boundary without extra mapping.

Drizzle Kit generates migrations from your schema. After changing the schema, run the generate command and apply the generated SQL. Keep the drizzle folder in version control so that every environment applies the same migrations.

TypeORM is a mature decorator-driven ORM with a large feature set. It supports migrations, subscribers, repositories, and complex relations. It is a good fit when your team is already familiar with it, or when you need an ORM with a more traditional object-oriented API. However, TypeORM can be heavy and is not always ideal for serverless environments where connection management is critical.

MikroORM is another alternative that emphasizes unit of work and identity map patterns. It is excellent for complex domains and gives you strong control over object identity and lazy loading. Kysely sits at the opposite end of the spectrum: it is a type-safe SQL query builder, not an ORM, and is perfect for teams that prefer explicit SQL over generated queries.

Raw SQL is not an admission of defeat. For analytical queries, heavy aggregations, or migrations that are hard to express in an ORM, a raw driver or a query builder is often clearer. The best stack is usually a hybrid: an ORM for CRUD operations and migrations, and a query builder for performance-critical paths.

The Edge Runtime in Next.js is lightweight and has no Node.js TCP networking stack. A database driver that opens a long-lived TCP connection will not work on the edge. Instead, edge-compatible databases expose an HTTP API that can be called with fetch, making them ideal for serverless functions and Vercel Edge Functions.

Neon, PlanetScale, Turso, Vercel Postgres, and Supabase all offer HTTP access. Neon and Vercel Postgres are PostgreSQL-compatible with a serverless driver. PlanetScale is MySQL-compatible through its serverless driver. Turso is libSQL-based and runs SQLite at the edge. Supabase provides a REST API through PostgREST and can be accessed from the edge with row-level security.

When you choose an edge database, you are not just choosing a protocol; you are choosing a deployment model where connections are short-lived and cold starts matter. HTTP drivers are stateless and pay a small per-query latency cost, while TCP drivers offer lower latency and richer session features but require pooling infrastructure.

In a traditional server, an application opens a pool of database connections at startup and reuses them for the lifetime of the process. In a serverless function, every request may run in a fresh process, and each process can open its own connections. Without pooling, a traffic spike can exhaust the database connection limit and cause cascading failures.

Connection pooling solves this by placing a proxy between the application and the database. PgBouncer is the classic PostgreSQL connection pooler. Modern managed services abstract this away: Neon, Supabase, and Vercel Postgres all provide connection pooling as part of their pooled connection strings. For AWS RDS, you can use RDS Proxy or run PgBouncer on a small container.

Prisma Accelerate is a managed connection pool and query cache that sits in front of your database. It is especially useful when you want to run Prisma on the edge or in serverless environments where the native engine is hard to manage. The connection string starts with prisma://and routes queries through Accelerate's edge network.

Cold starts also affect database workflows. A freshly started function must establish a connection, initialize the ORM client, and sometimes run migrations. Keep initialization code lightweight, use a singleton client, and avoid running heavy queries inside the first request. Warm pools and provisioned concurrency help if your latency budget is tight.

Server Actions let you call server-side functions directly from the client, typically from forms. They are the recommended way to handle mutations in the App Router. Because they run on the server, they can access the database, environment variables, and cookies, and they include CSRF protection by default.

A well-written mutation validates input, runs the write inside a transaction when needed, and returns a structured result. The UI can then use that result to display errors, trigger revalidation, or apply optimistic updates. Avoid leaking raw database errors to the client; map them to user-friendly messages.

For transactions, wrap multiple writes in a single database transaction. In Prisma, use prisma.$transaction. In Drizzle, use db.transaction. This keeps related changes atomic and consistent. If one step fails, the database rolls back all of them, preventing partial updates that corrupt state.

Optimistic updates are a UI pattern that assumes the mutation will succeed and updates the interface immediately. When the server responds, the UI reconciles the optimistic state with the actual result. The Next.js App Router supports this through useOptimistic in a client component that wraps the form. The Server Action itself remains the source of truth.

Next.js caches data fetched during rendering. By default, fetch calls are cached unless you opt out with dynamic rendering. But database queries made through an ORM are not fetch calls, so they are not cached automatically. To cache ORM queries, you can use the unstable_cache helper or wrap the query in a fetch request with a custom cache tag.

Caching is a powerful tool, but it introduces a trade-off between freshness and performance. Cache user-specific or frequently changing data sparingly. Cache semi-static reference data, product catalogs, and published posts more aggressively. Always measure the hit rate and invalidate on relevant mutations.

In a Server Component, you can call the cached function directly. The first render stores the result, and subsequent renders within the revalidation window serve the cached value. When a post is created, updated, or deleted, call revalidateTag("posts") to purge the cache and refresh the data on the next request.

Some teams prefer to wrap the database query in a fetch call with a custom cache tag. This works because Next.js caches fetch responses automatically. You can pass a cache key and revalidate time, but the response body must be serializable JSON. This approach is useful when you want to share a cache between server and client fetches.

A healthy database layer in Next.js is built on a small set of habits: keep the client off the database, validate inputs, reuse connections, handle errors gracefully, and cache with intention. These practices compound over time and prevent the most common production failures.