Fullstack interviews always reach the database: "which one and why", "how do you handle migrations", "this query is slow", "how does your app connect from a serverless function". The answers are mostly standard backend knowledge, applied through the tools Nuxt teams actually use in 2026: Drizzle first, Prisma second, Postgres by default, SQLite at the edge.

Know

• Choosing a store: Postgres is the default relational database (Neon, Supabase, RDS, self-hosted): constraints, joins, JSONB, full-text search, mature tooling. SQLite shines for small or edge deployments (Cloudflare D1, Turso/libsql, node:sqlite) and for tests. MySQL/PlanetScale where the organisation already runs it. Key-value stores (Redis, Cloudflare KV, Vercel KV) for caches, sessions and rate limits, not as the primary store. Object storage (S3, R2) for files. Document databases when the data is genuinely document-shaped; most product data is relational.
• ORMs and builders: Drizzle (v1) is SQL-like TypeScript with schema-as-code, drizzle-kit generate/migrate/push/studio, relational queries (db.query.orders.findMany({ with: { items: true } }), v2 relations via defineRelations), tiny runtime, edge-friendly drivers. Prisma has a schema DSL and a generated client with excellent DX and a larger runtime; recent versions dropped the Rust engine for a TypeScript client and support edge drivers. Kysely is a type-safe query builder without an ORM layer. The trade-off: Drizzle stays close to SQL and to the wire; Prisma abstracts more.
• Migrations: generated from the schema, committed, reviewed like code, applied in CI/CD before the new version serves traffic, and written backward compatible (expand → migrate data → contract) so old and new instances coexist during a rolling deploy; never push to production.
• Connections: a pool is process-level and belongs at module scope in server/utils/db.ts (one of the few legitimate module singletons). In serverless each instance opens its own connections and can exhaust Postgres, so use a pooler (PgBouncer, Neon's serverless driver over HTTP/WebSocket, Supabase's pooler, Cloudflare Hyperdrive) and keep pool sizes small. Edge runtimes need drivers that speak HTTP or WebSocket, not raw TCP.
• Transactions: db.transaction(async (tx) => ...) for multi-statement invariants (create order + decrement stock); know isolation levels (read committed default in Postgres; serializable for money) and that long transactions block; retries on serialization failures.
• N+1 and joins: a loop of queries per row is the classic slow endpoint; use joins, relational queries with with, or IN (...) batches; measure with query logging in development.
• Indexes: B-tree for equality and ranges, composite indexes ordered by selectivity and query shape, covering indexes to avoid table lookups, partial indexes for common filters (WHERE deleted_at IS NULL), GIN for JSONB and full-text; every foreign key gets an index; EXPLAIN (ANALYZE, BUFFERS) tells the truth. Indexes cost writes and space, so they follow real queries.
• Pagination: offset pagination is simple and jumps to pages but drifts and slows at depth; keyset (WHERE (created_at, id) < ($1, $2) ORDER BY created_at DESC, id DESC LIMIT n) is stable and fast and is what APIs and infinite feeds should expose as an opaque cursor.
• Concurrency and identity: optimistic concurrency with a version column and If-Match/412; UUIDv7 or ULIDs for time-ordered ids that do not leak counts (v7 is index-friendly, unlike v4); soft deletes with deleted_at when history matters; created_at/updated_at everywhere.
• Data access layer: repositories or services in server/utils take the db as a parameter (testability), handlers never write SQL, and rows are mapped to DTOs so a password_hash column can never reach a response.
• Nitro storage: useStorage(base) over unstorage drivers configured in nitro.storage (fs in dev, redis, cloudflare-kv-binding, cloudflare-r2-binding, vercel-kv, s3, memory); right for cache entries, sessions, small blobs; not a database. NuxtHub provides Cloudflare-native database, KV and blob helpers and moved to self-hosting and multi-vendor in 2026 after its Admin sunset.
• Operations: backups and point-in-time recovery, read replicas for reporting, connection and slow-query metrics, and a plan for schema changes on large tables (concurrent index creation, batched backfills).

How it works

Schema, connection and a service with Drizzle on Postgres:

import { index, integer, pgTable, text, timestamp, uuid } from 'drizzle-orm/pg-core'

export const users = pgTable('users', {
  id: uuid('id').primaryKey().defaultRandom(),
  email: text('email').notNull().unique(),
  passwordHash: text('password_hash').notNull(),
  role: text('role', { enum: ['admin', 'customer'] }).notNull().default('customer'),
  createdAt: timestamp('created_at', { withTimezone: true }).notNull().defaultNow(),
})

export const orders = pgTable('orders', {
  id: uuid('id').primaryKey().defaultRandom(),
  userId: uuid('user_id').notNull().references(() => users.id),
  totalMinor: integer('total_minor').notNull(),
  version: integer('version').notNull().default(1),
  createdAt: timestamp('created_at', { withTimezone: true }).notNull().defaultNow(),
}, t => [index('orders_user_created_idx').on(t.userId, t.createdAt.desc(), t.id)]) // keyset pagination per user

import { drizzle } from 'drizzle-orm/node-postgres'
import { Pool } from 'pg'
import * as schema from '~~/server/db/schema'

// Process-level pool: one of the few legitimate module singletons on the server.
const pool = new Pool({ connectionString: useRuntimeConfig().databaseUrl, max: 5 }) // small: a pooler in front handles fan-out
export const db = drizzle(pool, { schema })
export type Db = typeof db
export const useDb = () => db

import { and, desc, eq, lt, or, sql } from 'drizzle-orm'
import { orders } from '~~/server/db/schema'

export async function listOrdersForUser(db: Db, userId: string, cursor?: { createdAt: Date, id: string }, limit = 20) {
  const rows = await db.select().from(orders)
    .where(and(eq(orders.userId, userId), cursor
      ? or(lt(orders.createdAt, cursor.createdAt), and(eq(orders.createdAt, cursor.createdAt), lt(orders.id, cursor.id)))
      : undefined))
    .orderBy(desc(orders.createdAt), desc(orders.id))
    .limit(limit + 1) // one extra row tells us whether there is a next page
  const items = rows.slice(0, limit)
  const last = items.at(-1)
  return { items, nextCursor: rows.length > limit && last ? encodeCursor({ createdAt: last.createdAt, id: last.id }) : null }
}

export async function updateOrderNote(db: Db, id: string, userId: string, note: string, expectedVersion: number) {
  const [row] = await db.update(orders)
    .set({ note, version: sql`${orders.version} + 1` })
    .where(and(eq(orders.id, id), eq(orders.userId, userId), eq(orders.version, expectedVersion))) // optimistic concurrency
    .returning()
  if (!row) throw createError({ status: 412, statusText: 'Order was modified' })
  return row
}

export async function placeOrder(db: Db, input: { userId: string, items: { productId: string, qty: number }[] }) {
  return db.transaction(async (tx) => {
    const products = await tx.query.products.findMany({ where: (p, { inArray }) => inArray(p.id, input.items.map(i => i.productId)) }) // one query, not N
    // ... compute total, decrement stock with a guarded update, insert order + items; all or nothing
  })
}

Migrations in the pipeline, and Nitro storage for what is not relational:

pnpm drizzle-kit generate           # SQL migration from schema diff, committed with the PR
pnpm drizzle-kit migrate            # in CD, before the new version takes traffic

export default defineNuxtConfig({
  nitro: {
    storage: {
      cache: { driver: 'redis', url: process.env.REDIS_URL },     // shared across instances
      uploads: { driver: 's3', bucket: 'app-uploads', region: 'eu-central-1' },
    },
    devStorage: { cache: { driver: 'fs', base: '.data/cache' }, uploads: { driver: 'fs', base: '.data/uploads' } },
  },
})

Exercise

Be able to say