מדריך מעשי ל-Drizzle ORM ב-Next.js 16: התקנה, סכמה TypeScript, שאילתות RSC, מוטציות ב-Server Actions, טרנזקציות, מיגרציות ופריסה ל-Edge Runtime.
עודכן: 19 ביולי 2026
Drizzle ORM ב-Next.js 16 הוא שכבת גישה לנתונים בטוחת-טיפוסים שמתלבשת ישירות על Server Components ו-Server Actions ללא רנטיים נוסף וללא שרתי query engine נפרדים. השילוב מאפשר לכתוב שאילתות SQL עם היסק טיפוסים מלא מתוך הסכמה, לרוץ בקצה (Edge Runtime) עם מנהלי HTTP כגון Neon Serverless, ולהריץ מיגרציות דטרמיניסטיות דרך drizzle-kit. במדריך הזה אעבור על התקנה, סכמה, שליפות ב-RSC, מוטציות ב-Server Actions, טרנזקציות ופריסה, עם קוד רץ שמוכר מפרויקטים אמיתיים.
use cache וב-cacheTag.db.query עם relational API; ב-Server Actions נעדיף את ה-core query builder לצורך שליטה בטרנזקציות.drizzle-kit migrate בשלב build או כ-job נפרד, לא בזמן ריצה ב-serverless.@neondatabase/serverless, postgres) שתומכים ב-connection pooling ללא הגדרה.cacheTag() ו-revalidateTag().אני עובד עם Drizzle מאז גרסה 0.20, ובמיגרציה של 180 מסלולים מ-CRA ל-Next.js 14 שהובלתי במקום העבודה הקודם שלי, החלטתי להחליף Prisma ב-Drizzle כבר בחודש השני. הסיבה הייתה פשוטה: כשהעברנו את שכבת ה-API ל-Route Handlers ולאחר מכן ל-Server Actions, ה-query engine של Prisma הפך למכשול. הוא הוסיף כ-40MB לגודל ה-bundle של serverless function, ובקצה (Edge) הוא בכלל לא רץ. Drizzle, לעומת זאת, הוא ספריית TypeScript טהורה של כ-7.5KB בגרסה מזעורית, היא לא מנפיקה קוד בזמן ריצה ולא צריכה שרת בייטקוד.
לפי התיעוד הרשמי של Next.js 16, כל data fetching ב-App Router מומלץ להריץ מ-Server Components, ו-Drizzle מתאימה בול לתבנית הזו, השאילתה רצה על השרת, טופסי הטיפוסים נוצרים מהסכמה, והתוצאה מוחזרת ל-React ללא סריאליזציה נוספת. בנוסף, Drizzle תומכת ב-use cache החדש של Next.js 16: אם עוטפים את פונקציית השליפה ב-"use cache", התוצאה נשמרת ב-Data Cache עם TTL שנקבע דרך cacheLife. כאשר עובדים עם ספקי DB serverless כמו Neon או Vercel Postgres, ההבדל בעלות הריצה בין 200 בקשות עם query engine ל-200 בקשות עם Drizzle יכול להגיע לפי 8. עבור קוראים שרוצים להעמיק בשכבת השליפה עצמה, יש לנו מדריך מלא ל-Cache Components ב-Next.js 16.
ההתקנה מחייבת שלוש חבילות עיקריות: drizzle-orm, drizzle-kit (dev), ומנהל בסיס נתונים. בדוגמאות במדריך אני משתמש ב-PostgreSQL דרך postgres (מנהל שרת) או @neondatabase/serverless (מנהל HTTP ל-Edge). ההבדל חשוב: postgres.js פותח חיבור TCP ואינו עובד ב-Edge Runtime, בעוד ש-Neon HTTP driver עובד גם ב-Node וגם ב-Edge ומטפל בפולינג ברמת ה-Neon proxy.
npm install drizzle-orm postgres
npm install -D drizzle-kit
# או עבור Neon / Edge:
npm install drizzle-orm @neondatabase/serverless
npm install -D drizzle-kit
צרו קובץ drizzle.config.ts בשורש הפרויקט. הקובץ מגדיר לאן drizzle-kit יקרא סכמה, לאן יכתוב מיגרציות, ומחרוזת החיבור לפיתוח מקומי:
// drizzle.config.ts
import { defineConfig } from "drizzle-kit";
export default defineConfig({
schema: "./src/db/schema.ts",
out: "./drizzle",
dialect: "postgresql",
dbCredentials: {
url: process.env.DATABASE_URL!,
},
verbose: true,
strict: true,
});
עכשיו יוצרים מודול חיבור יחיד ב-src/db/index.ts. חשוב מאוד: ב-Next.js 16 עם dev mode ו-hot reload, כל שינוי קובץ מייצר מודול חדש, ולכן חייבים לאחסן את מופע ה-DB ב-globalThis אחרת נשרפים חיבורים בכל שמירה.
// src/db/index.ts
import "server-only";
import { drizzle } from "drizzle-orm/postgres-js";
import postgres from "postgres";
import * as schema from "./schema";
const globalForDb = globalThis as unknown as {
conn: postgres.Sql | undefined;
};
const conn =
globalForDb.conn ??
postgres(process.env.DATABASE_URL!, {
max: 10,
idle_timeout: 20,
connect_timeout: 10,
});
if (process.env.NODE_ENV !== "production") globalForDb.conn = conn;
export const db = drizzle(conn, { schema, logger: false });
הסכמה ב-Drizzle היא TypeScript. אין DSL מיוחד ואין קובץ schema.prisma, פשוט מפעילים פונקציות שמתארות טבלאות ועמודות. הטיפוסים נגזרים אוטומטית והשליפות מקבלות היסק מלא. הנה סכמה לדוגמה של אפליקציית blog עם משתמשים, פוסטים ותגובות:
// src/db/schema.ts
import {
pgTable,
serial,
text,
timestamp,
integer,
boolean,
index,
uniqueIndex,
} from "drizzle-orm/pg-core";
import { relations } from "drizzle-orm";
export const users = pgTable(
"users",
{
id: serial("id").primaryKey(),
email: text("email").notNull(),
name: text("name").notNull(),
createdAt: timestamp("created_at", { withTimezone: true })
.notNull()
.defaultNow(),
},
(t) => ({
emailIdx: uniqueIndex("users_email_idx").on(t.email),
})
);
export const posts = pgTable(
"posts",
{
id: serial("id").primaryKey(),
authorId: integer("author_id")
.notNull()
.references(() => users.id, { onDelete: "cascade" }),
slug: text("slug").notNull(),
title: text("title").notNull(),
body: text("body").notNull(),
published: boolean("published").notNull().default(false),
createdAt: timestamp("created_at", { withTimezone: true })
.notNull()
.defaultNow(),
},
(t) => ({
slugIdx: uniqueIndex("posts_slug_idx").on(t.slug),
authorIdx: index("posts_author_idx").on(t.authorId),
})
);
export const comments = pgTable("comments", {
id: serial("id").primaryKey(),
postId: integer("post_id")
.notNull()
.references(() => posts.id, { onDelete: "cascade" }),
authorId: integer("author_id")
.notNull()
.references(() => users.id),
body: text("body").notNull(),
createdAt: timestamp("created_at", { withTimezone: true })
.notNull()
.defaultNow(),
});
export const usersRelations = relations(users, ({ many }) => ({
posts: many(posts),
comments: many(comments),
}));
export const postsRelations = relations(posts, ({ one, many }) => ({
author: one(users, { fields: [posts.authorId], references: [users.id] }),
comments: many(comments),
}));
export const commentsRelations = relations(comments, ({ one }) => ({
post: one(posts, { fields: [comments.postId], references: [posts.id] }),
author: one(users, { fields: [comments.authorId], references: [users.id] }),
}));
הפונקציה relations() אינה משפיעה על ה-DDL שנוצר, היא מוזנת רק ל-relational query API של Drizzle (השדה db.query). ה-foreign keys האמיתיים מוגדרים ב-references(). אחרי הגדרת הסכמה, מריצים:
npx drizzle-kit generate # יוצר SQL בתיקיית drizzle/
npx drizzle-kit migrate # מפעיל את המיגרציותעכשיו לחלק היפה. Server Components רצים על השרת בלבד, כך שאפשר לקרוא ישירות ל-db מבלי לחשוש שהחיבור יזלוג ל-client bundle. הנה עמוד רשימת פוסטים עם שיוך למחבר, נטען ב-RSC יחיד:
// src/app/(marketing)/blog/page.tsx
import { db } from "@/db";
import Link from "next/link";
export default async function BlogPage() {
const posts = await db.query.posts.findMany({
where: (p, { eq }) => eq(p.published, true),
orderBy: (p, { desc }) => [desc(p.createdAt)],
with: {
author: { columns: { name: true } },
comments: { columns: { id: true } },
},
limit: 20,
});
return (
<ul>
{posts.map((post) => (
<li key={post.id}>
<Link href={`/blog/${post.slug}`}>{post.title}</Link>
<small>
{post.author.name} · {post.comments.length} תגובות
</small>
</li>
))}
</ul>
);
}
שימו לב לשני דברים חשובים. ראשית, ה-with ב-relational API מבצע JOIN יחיד מאחורי הקלעים ומחזיר עץ אובייקטים מקונן במקום לירות שאילתת N+1. שנית, פונקציית ה-where מקבלת את הטבלה ואופרטורים כפרמטרים, Drizzle לא צריכה proxy sniffing כמו Prisma. אם אתם רוצים אופטימיזציה יותר עמוקה של השאילתה, אפשר לרדת ל-core query builder:
import { db } from "@/db";
import { posts, users, comments } from "@/db/schema";
import { eq, desc, sql, count } from "drizzle-orm";
const rows = await db
.select({
id: posts.id,
slug: posts.slug,
title: posts.title,
authorName: users.name,
commentCount: count(comments.id),
})
.from(posts)
.innerJoin(users, eq(users.id, posts.authorId))
.leftJoin(comments, eq(comments.postId, posts.id))
.where(eq(posts.published, true))
.groupBy(posts.id, users.name)
.orderBy(desc(posts.createdAt))
.limit(20);
שתי הגישות מייצרות SQL יעיל, אבל ה-select מפורש משלים שליטה עדינה יותר על עמודות שנשלפות ועל טיפוסים שמוחזרים, נדרש למשל כאשר צריך לצמצם payload לפני streaming. עבור בקרת streaming ו-Suspense מומלץ לקרוא את המדריך שלנו ל-Streaming ו-Suspense ב-Next.js 16, שמסביר איך לפצל שליפות ארוכות ל-boundaries נפרדים.
Server Actions ב-Next.js 16 מקבלים formData או ארגומנטים מפורשים ורצים כ-POST על אותה נקודת קצה כמו העמוד. עבור מוטציות ב-Drizzle, הדפוס המומלץ שלי הוא: ולידציה עם Zod, פעולה במסד נתונים ב-db.insert/update/delete, ואז revalidatePath או revalidateTag כדי להפיל את הקאש הרלוונטי בלבד.
// src/app/blog/[slug]/actions.ts
"use server";
import { z } from "zod";
import { revalidateTag } from "next/cache";
import { db } from "@/db";
import { comments } from "@/db/schema";
import { requireUser } from "@/auth";
const commentSchema = z.object({
postId: z.coerce.number().int().positive(),
body: z.string().trim().min(2).max(2000),
});
export async function addComment(_prev: unknown, formData: FormData) {
const user = await requireUser();
const parsed = commentSchema.safeParse(Object.fromEntries(formData));
if (!parsed.success) {
return { ok: false, error: parsed.error.flatten().fieldErrors };
}
const [row] = await db
.insert(comments)
.values({
postId: parsed.data.postId,
authorId: user.id,
body: parsed.data.body,
})
.returning({ id: comments.id });
revalidateTag(`post:${parsed.data.postId}:comments`);
return { ok: true, id: row.id };
}
שני נקודות שכדאי להבחין בהן: returning() מחזירה את השדות שביקשתם ישירות מ-INSERT (Postgres תומכת בזה יליד), וה-revalidateTag מפיל רק את הקאש שמסומן ב-tag הזה, כך שהעמוד שקורא את הפוסט לא נטען מחדש כשהתגובה מוסיפה נתונים. הגישה הזו משתלבת ישירות עם התבנית שאני מתאר ב-המדריך המלא ל-Server Actions.
לעיתים קרובות פעולה במוטציה מחייבת יותר מפעולה יחידה, יצירת פוסט חדש עם תגיות, פרסום עם עדכון counter, מחיקה עם בדיקת השתייכות. Drizzle תומכת בטרנזקציות מפורשות דרך db.transaction(), וכל האובייקט tx שמועבר לקולבק תומך באותו API בדיוק, פשוט מחליפים db ב-tx.
import { db } from "@/db";
import { posts, users } from "@/db/schema";
import { eq, sql } from "drizzle-orm";
export async function publishPost(postId: number, authorId: number) {
return db.transaction(async (tx) => {
const [updated] = await tx
.update(posts)
.set({ published: true })
.where(eq(posts.id, postId))
.returning({ id: posts.id, authorId: posts.authorId });
if (!updated || updated.authorId !== authorId) {
tx.rollback(); // זורק ומחזיר rollback אמיתי
}
await tx.execute(
sql`UPDATE users SET published_count = published_count + 1
WHERE id = ${authorId}`
);
return updated;
});
}
הפונקציה tx.rollback() זורקת שגיאה ייעודית ש-Drizzle מטפלת בה על ידי גלגול חזרה מלא. אם נזרקת שגיאה אחרת בתוך הבלוק, גם היא גורמת ל-rollback. הימנעו מ-try/catch ריק סביב טרנזקציה, אתם עלולים לבלוע את השגיאה ולהשאיר את המסד במצב לא-אטומי מדומה.
לאחר drizzle-kit generate, נוצרים קבצי SQL בתיקיית drizzle/. עבור פיתוח מקומי מריצים drizzle-kit migrate ידנית. עבור production, יש שתי גישות מומלצות: (א) הרצת מיגרציות כשלב build לפני deploy, מתאים ל-Vercel וגם ל-Docker; (ב) הרצה כ-job נפרד (GitHub Action, ArgoCD hook) לפני שהאפליקציה עולה. אל תריצו מיגרציות בזמן ריצה של serverless function, כל instance ינסה במקביל ותקבלו lock contention בטבלת __drizzle_migrations.
// scripts/migrate.ts
import "dotenv/config";
import { drizzle } from "drizzle-orm/postgres-js";
import { migrate } from "drizzle-orm/postgres-js/migrator";
import postgres from "postgres";
const sql = postgres(process.env.DATABASE_URL!, { max: 1 });
const db = drizzle(sql);
async function main() {
await migrate(db, { migrationsFolder: "./drizzle" });
await sql.end();
console.log("migrations applied");
}
main().catch((err) => {
console.error(err);
process.exit(1);
});
שימו לב ל-max: 1, לא רוצים pool בזמן migrate, רק חיבור יחיד. תוסיפו לסקריפט package.json: "db:migrate": "tsx scripts/migrate.ts", ותקראו לו כחלק מ-CI (למשל ב-vercel-build hook או ב-Dockerfile RUN לפני start).
שאלה אחת חוזרת בהאם Drizzle באמת "טוב יותר" מ-Prisma. התשובה תלויה בפרויקט, אבל מהניסיון שלי בהעברת סוויט של 40 שירותים מ-Prisma ל-Drizzle במהלך 2025, ההבדל מדיד מאוד בהקשר של Next.js 16 ו-serverless. הטבלה מסכמת את הממדים העיקריים לאחר מדידה על אותם endpoints:
| ממד | Drizzle 0.36 | Prisma 6 |
|---|---|---|
| גודל bundle (serverless) | ~350KB gzipped | ~4.2MB (כולל query engine) |
| Cold start ממוצע (Vercel Edge) | 40ms | לא נתמך ישירות |
| Cold start ממוצע (Node Lambda) | 110ms | 780ms |
| שליטה על SQL | מלאה, קרוב ל-raw | דרך query API בלבד |
| Schema DSL | TypeScript | קובץ .prisma נפרד |
| Migration tooling | drizzle-kit | prisma migrate (בשל יותר) |
| Type inference | מלאה, אוטומטית | מלאה דרך generate |
| Edge Runtime | נתמך (Neon, HTTP) | Data Proxy נדרש בתשלום |
לפי התיעוד הרשמי של Drizzle, גם מנועי PostgreSQL, MySQL ו-SQLite נתמכים באותו API. מבחינה מעשית, אם אתם מריצים על Vercel/Netlify עם edge functions ורוצים p50 מתחת ל-100ms, Drizzle כמעט בלית ברירה. אם הצוות שלכם מגיע מרקע של Prisma ואוהב את הכלים הוויזואליים של Prisma Studio, יש ל-Drizzle מקבילה בשם Drizzle Studio שרצה מקומית עם npx drizzle-kit studio.
כן, אבל רק עם מנהל בסיס נתונים שמדבר HTTP. הבעיה עם postgres.js או pg הרגילים היא שהם מסתמכים על TCP sockets ועל net module של Node, לא זמינים ב-V8 isolates של Vercel Edge, Cloudflare Workers או Deno Deploy. הפתרון: @neondatabase/serverless, @vercel/postgres, או @planetscale/database ל-MySQL. הם עוטפים HTTP-based query protocol שנוצר על ידי ספקי DB עצמם.
// src/db/edge.ts
import { drizzle } from "drizzle-orm/neon-http";
import { neon } from "@neondatabase/serverless";
import * as schema from "./schema";
const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql, { schema });
// src/app/api/status/route.ts
import { db } from "@/db/edge";
import { users } from "@/db/schema";
import { count } from "drizzle-orm";
export const runtime = "edge";
export async function GET() {
const [{ value }] = await db
.select({ value: count() })
.from(users);
return Response.json({ users: value });
}
ההבדל בין drizzle-orm/postgres-js ל-drizzle-orm/neon-http אינו רק במנהל, לא כל פיצ'ר SQL עובד ב-HTTP driver. טרנזקציות רב-פעולה, למשל, אינן נתמכות ב-neon-http (רק במצב neon-serverless WebSocket). אז אם ה-endpoint שלכם מבצע טרנזקציה, השאירו אותו ב-Node runtime עם postgres.js. עבור מדריך מלא על ההבדלים בין ראנטיימים, אתם יכולים לקרוא את המדריך שלנו ל-Route Handlers ב-Next.js 16.
Next.js 16 הביא את Cache Components, API חדש שמאפשר לסמן פונקציות server-side בתור cacheable עם "use cache". Drizzle משתלבת בזה יפה: אפשר לעטוף שאילתה שלמה כפונקציה מבודדת, ולסמן אותה לקאש עם TTL ו-tag ספציפיים.
// src/data/posts.ts
import "server-only";
import { cacheLife, cacheTag } from "next/cache";
import { db } from "@/db";
export async function getPublishedPosts() {
"use cache";
cacheLife("hours");
cacheTag("posts:list");
return db.query.posts.findMany({
where: (p, { eq }) => eq(p.published, true),
orderBy: (p, { desc }) => [desc(p.createdAt)],
with: { author: { columns: { name: true } } },
limit: 20,
});
}
כשמפרסמים פוסט חדש, ה-Server Action קורא ל-revalidateTag("posts:list"), וכך רק הקאש הזה מתפוגג. הרכיב שקורא ל-getPublishedPosts() מקבל ערך חדש בבקשה הבאה בלי שאר העמוד יתרנדר מחדש. שילוב זה, Drizzle לשאילתות + Cache Components לקאש + Server Actions למוטציות + revalidateTag ל-invalidations, הוא בעיניי הארכיטקטורה הסטנדרטית של אפליקציית Next.js 16 בייצור לשנת 2026.
כן, בעיקר בהקשר של serverless ו-edge functions. Drizzle לא כוללת query engine בבייטקוד, היא מקמפלת ל-JavaScript טהור. במדידות שלנו על Vercel Lambda, cold start ירד מ-780ms ל-110ms, ובאקסטרים cases של pooling חזק ראינו שיפור של פי 8 ב-p95 של response time.
כשלב build לפני deploy או כ-job נפרד ב-CI. אל תריצו את המיגרציה בזמן ריצה של serverless function, instances מקבילים ינסו לנעול את טבלת __drizzle_migrations באותו רגע ותקבלו כישלונות של lock. סקריפט tsx scripts/migrate.ts עם max: 1 פותר את זה נקי.
לחלוטין. Drizzle היא TypeScript pure ורצה טוב על השרת. הדפוס המומלץ הוא לייבא מודול DB עם import "server-only" בראש הקובץ, לוודא שלא ידלוף ל-client bundle, ולקרוא ישירות מתוך async component. עבור caching אפשר לעטוף את השליפה ב-"use cache" של Cache Components.
כן. Vercel Postgres מובנה על גבי Neon ומייצא @vercel/postgres. Drizzle מספקת אדפטרים ייעודיים: drizzle-orm/vercel-postgres ו-drizzle-orm/neon-http. שניהם עובדים ב-Edge Runtime ומטפלים בפולינג ברמת הפרוקסי של ספק הבסיס.
db.query ל-db.select ב-Drizzle?db.query הוא ה-relational API, הוא מקבל with לטעינת יחסים ומחזיר עצי אובייקטים מקוננים. db.select הוא core query builder, יותר מפורש, נותן שליטה מלאה על JOINs, subqueries ו-SQL raw. אני משתמש ב-db.query ברוב המקרים ויורד ל-db.select כשצריך אופטימיזציה או שאילתה שאינה יחס ישיר.