编程 Drizzle ORM v1.0.0-rc.1 深度实战：当 TypeScript ORM 遇见 Bun SQL——JIT Row Mappers、Effect 集成与超越 Go 的性能神话（2026）

2026-06-18 12:25:32 +0800 CST views 3

Drizzle ORM v1.0.0-rc.1 深度实战：当 TypeScript ORM 遇见 Bun SQL——JIT Row Mappers、Effect 集成与超越 Go 的性能神话（2026）

前言

2026年五一假期，整个技术社区被一张基准测试截图点燃了。

Drizzle ORM 官方在发布 v1.0.0-rc.1 时，随手在社交媒体贴了一张对比图：左边是 Drizzle ORM 跑在 Bun 运行时上，平均延迟 7.3ms，吞吐量 8.8k req/sec；右边是 Go v1.25.5 的某个标准服务实现，平均延迟 18.1ms，吞吐量 8.2k req/sec。

Bun 官方账号第一时间转发，只配了一句话："faster than Go, uses Bun, Many such cases."

更耐人寻味的是 Vue.js 和 Vite 的作者尤雨溪（Evan You）也转发了这条推文，轻描淡写地说了一句"正好赶在 Void 公测前把依赖版本更新一下"。

这意味着什么？在服务端 JavaScript/TypeScript 领域，2026 年的我们正在见证一个重要的转折点：TypeScript ORM 配合高性能运行时，第一次在硬核性能指标上正面超越了 Go。

但数字背后是什么？JIT Row Mappers 是怎么把 ORM 开销压到接近零的？Drizzle 和 Prisma 的恩怨情仇到底在争什么？这一切对生产环境的你意味着什么？

本文将深入拆解 Drizzle ORM v1.0.0-rc.1 的每一个核心特性，从架构原理到代码实战，从基准测试解读到生产迁移指南，目标是让你读完就能在自己的项目中做出正确的技术选型决策。

一、背景铺垫：为什么 Drizzle ORM 值得关注

1.1 TypeScript ORM 的战国时代

在 2026 年的 TypeScript 生态里，ORM 领域已经形成了相对清晰的格局：

Prisma 是最早一批把"类型安全"概念普及给前端开发者的 ORM。它的 Schema 定义方式、自动生成的客户端、完善的迁移系统，让很多团队从"裸写 SQL"一步跨入"类型安全时代"。但 Prisma 的代价是：体积庞大、运行时复杂、在边缘计算环境（Cloudflare Workers、Vercel Edge Functions）表现不佳，以及那条让很多人又爱又恨的 Prisma DSL——用惯了 SQL 的开发者，总觉得在写一门新语言。

Drizzle ORM 则是另一个极端。它的设计哲学是："写 Drizzle 就像写 SQL，只是带了类型注解"。没有 Schema 自动生成，没有专属 DSL，没有黑盒式的查询引擎——Schema 是 TypeScript 代码，查询也是 TypeScript 代码，最终执行的就是你看得懂的 SQL。这种"透明感"对于后端开发者来说，是莫大的信任感。

Kysely 则更纯粹，是一个 TypeScript 类型的查询构建器，几乎没有 ORM 层的封装，适合那些希望完全掌控 SQL 生成的团队。

在这三者之间，Drizzle 找到了一个巧妙的平衡点：它比 Kysely 多了一些抽象便利，又比 Prisma 轻量得多、更贴近 SQL 原语。这几年在 Hono、Elysia、Fastify 等轻量框架社区里，Drizzle 的采用率在持续攀升。

1.2 Bun：JavaScript 运行时的新天花板

Bun 的出现彻底改变了 JavaScript 服务端开发的性能基准线。

与 Node.js 不同，Bun 从一开始就把性能写进了自己的核心设计里：基于 JavaScriptCore 引擎（而不是 V8）、原生内置 TypeScript 编译、SQI（SQLite）内置支持，以及对数据库连接池的底层优化。Bun 1.3.x 版本已经对 PostgreSQL、MySQL 等主流数据库的驱动进行了深度优化，在连接管理、查询执行、结果集处理等环节都比 Node.js 有显著优势。

更关键的是，Bun 还内置了 bun:sql 模块，这是一个轻量的、零依赖的数据库查询接口。相比传统的 Node.js 数据库驱动，bun:sql 在网络 IO 和数据序列化层面做了大量底层优化。

所以当 Drizzle ORM 的 JIT Row Mappers 技术遇上 Bun SQL 的底层优化，产生的化学反应就造就了开头那张让人目瞪口呆的基准测试图。

二、Drizzle ORM v1.0.0-rc.1 核心特性深度解析

2.1 JIT Row Mappers：把 ORM 开销压到接近零

这是 v1.0.0-rc.1 最核心、最具颠覆性的特性。

2.1.1 传统 ORM 的性能瓶颈在哪里

要理解 JIT Row Mappers 的价值，首先需要知道传统 ORM 在"把数据库结果变成 JavaScript 对象"这一步到底有多慢。

以 Prisma 为例。当你执行一条 select().from(users) 查询时，数据库返回的结果是一个扁平的行数组，类似这样：

[[1, "alice@example.com", "Alice Chen", "2026-01-15T08:30:00Z"], [2, "bob@example.com", "Bob Wang", "2026-02-20T10:15:00Z"]]

Prisma 需要把这个数组中的每个值映射到对应的 Schema 字段上：判断字段类型（Int → Number，String → String，DateTime → Date 对象），处理关联关系（join 结果需要拆分到不同表的实体），处理 nullable 字段，处理默认值和计算字段……

这个过程在高并发场景下会成为一个显著的性能瓶颈：

// 伪代码：传统 ORM 的行映射过程
function mapRowToUser(row: any[]): User {
  const user = new User();
  for (const field of userSchema.fields) {
    const rawValue = row[field.columnIndex];
    if (field.isNullable && rawValue === null) {
      user[field.name] = null;
    } else if (field.type === 'Int') {
      user[field.name] = Number(rawValue);
    } else if (field.type === 'DateTime') {
      user[field.name] = new Date(rawValue);
    } else {
      user[field.name] = rawValue;
    }
  }
  return user;
}

每一条记录都要：

遍历所有字段（假设 20 个字段）
每个字段做类型判断和转换
处理关联关系（多表 JOIN 时尤其复杂）
分配新的对象实例

在高并发（1000 req/sec × 100 条记录/请求）场景下，这个"每条记录遍历所有字段做类型判断"的过程每秒要执行数万甚至数十万次，累计的 CPU 开销非常可观。

2.1.2 JIT Row Mappers 的解决思路

Drizzle v1.0.0-rc.1 的 JIT Row Mappers 换了一个思路：既然每条记录的字段结构和 Schema 是固定的，那映射函数本身也应该是固定的——而不是每次执行时动态判断。

核心原理如下：

第一步：Schema 级别的代码生成

Drizzle 在初始化数据库连接时，会根据你的 usersTable Schema 静态生成一个专门针对这张表的映射函数。这个函数知道：

users 表的第 0 列是 id（serial，映射为 number）
第 1 列是 email（text，直接字符串）
第 2 列是 fullName（text）
第 3 列是 createdAt（timestamp，需要 new Date() 转换）

生成的映射函数大概长这样：

// 编译时生成的这张表的专属映射函数（示意图）
function mapUsersRow(row: unknown[]): InferSelectModel<typeof usersTable> {
  return {
    id: row[0] as number,                                    // 直接类型断言，无判断
    email: row[1] as string,                                // 直接类型断言，无判断
    fullName: row[2] as string,                             // 直接类型断言，无判断
    createdAt: row[3] ? new Date(row[3] as string) : null,  // null检查只在必要时
  };
}

关键区别在于：没有 if (field.type === '...') 的运行时类型判断。映射逻辑在编译阶段就固化成了最短路径的代码，运行时只需要按顺序取值、断言、返回，不需要任何分支判断和动态派发。

第二步：Bun SQL 的零拷贝序列化

光有 JIT 映射还不够，Bun SQL 在数据库驱动层面也做了大量优化。传统 Node.js 的 PostgreSQL 驱动（如 pg）在接收数据库结果时，会把数据从数据库的二进制协议格式转换为 JavaScript 的字符串/数字表示，这个过程涉及大量内存分配和副本拷贝。

Bun SQL 在这一层使用了更激进的零拷贝策略：结果数据直接从数据库连接缓冲区映射到 JavaScript 可访问的内存区域，省去了中间层的内存复制。结合 JIT Row Mappers，数据的流向变成了：

数据库 → Bun SQL 零拷贝缓冲区 → JIT 映射函数 → 用户代码

整个路径上，每个字节只被读取一次，没有多余的分配和转换。

2.1.3 实际性能对比数据

Drizzle 官方基准测试的核心数据：

指标	Drizzle + Bun	Go + 某 ORM
平均延迟	7.3ms	18.1ms
吞吐量	8.8k req/sec	8.2k req/sec
CPU 利用率	81.6%	75.5%

需要特别注意的是 CPU 利用率：Drizzle 侧多用掉了约 6 个百分点的 CPU 换来了更低的延迟。这说明"低延迟"不是凭空产生的，是用算力换来的——这在实时交互型应用（API 网关、游戏后端、金融交易系统）中是合理的trade-off，但在 CPU 敏感的批处理场景可能不是最优解。

另外，这组对比中 Go 那侧的 ORM 选择、框架配置、数据库连接池设置都没有公开，理论上存在调优空间。所以结论应该是：Drizzle + Bun 已经具备和 Go 在特定场景下正面竞争的能力，而不是"JavaScript 天生比 Go 快"。

2.2 Effect v4 原生集成：函数式错误处理遇上类型安全数据库

2.2.1 Effect 是什么

Effect 是 TypeScript 生态里最成熟的函数式编程库之一，提供：

类型安全的错误处理：错误不是通过 throw/catch 传递，而是通过 Effect<E, A> 的 E 类型参数进行静态类型推导
依赖注入：通过 Context 实现松耦合的服务注册和获取
并发管理：Effect.gen 支持 async/await 语法，但底层是可控的 fiber 调度
资源管理：Ref, Queue, Semaphore 等并发原语

Effect 的设计哲学是：让错误在编译期就被发现，而不是等到运行时才爆炸。

2.2.2 Drizzle + Effect 的集成方式

v1.0.0-rc.1 之前，如果你想在 Effect 中使用 Drizzle，需要自己写适配层，错误处理和资源清理都很繁琐。现在 Drizzle 官方直接支持 Effect.gen 中的数据库操作：

import { PgClient } from '@effect/sql-pg';
import * as PgDrizzle from 'drizzle-orm/effect-postgres';
import * as Effect from 'effect/Effect';
import { eq } from 'drizzle-orm';
import { usersTable } from './schema';

// 构建数据库 Effect
const DB = PgDrizzle.make({ relations: true }).pipe(
  Effect.provide(PgDrizzle.DefaultServices)
);

// 在 Effect.gen 中直接操作数据库
const getUserByEmail = (email: string) =>
  Effect.gen(function* ($) {
    const db = yield* DB;
    const user = yield* db.select().from(usersTable).where(eq(usersTable.email, email));
    return user;
  }).pipe(
    Effect.provide(PgClientLive)  // 注入真实的数据库连接
  );

// 执行（自动处理连接获取和释放）
const result = await Effect.runPromise(getUserByEmail('alice@example.com'));

对比传统的 try/catch 写法：

// 传统写法：错误处理分散、类型不安全
async function getUserByEmail(email: string) {
  try {
    const user = await db.select().from(usersTable).where(eq(usersTable.email, email));
    return user;
  } catch (error) {
    console.error('Database error:', error);  // error 是 unknown 类型
    throw error;
  }
}

Effect 版本的类型推导保证了：如果你在代码里忘记处理可能的数据库错误，TypeScript 编译器就会报错。yield* db.select() 的返回类型已经包含了可能的错误类型，调用方必须显式处理或向上传递。

这对于构建高可靠性系统（金融、医疗、工业控制）来说，是非常有价值的约束。

2.3 Casing API 重构：统一命名策略

2.3.1 旧版问题

在 TypeScript 中，代码风格通常用 camelCase（fullName、createdAt）；在数据库中，列名通常用 snake_case（full_name、created_at）。ORM 的一个核心职责就是在两者之间做映射。

Drizzle 之前的版本中，这个映射是分散的：你在 table 定义里设置 columnName: text().$default(() => '...') 来处理 snake_case，有些插件或 helper 函数又会自己处理大小写转换，整个映射逻辑碎片化，容易出现"某些地方转了、某些地方没转"的不一致问题。

2.3.2 新的 Casing API

v1.0.0-rc.1 统一了命名策略，在 table 创建时直接声明：

import * as d from "drizzle-orm/pg-core";

// 整个 schema 统一使用 snake_case 策略
// TypeScript 代码中 fullName → 数据库列名 full_name
const users = d.snakeCase.table("users", {
  id: d.serial().primaryKey(),
  email: d.text().unique(),
  fullName: d.text(),        // 自动映射为 full_name
  createdAt: d.timestamp().defaultNow(),  // 自动映射为 created_at
});

// 也可以针对不同的 schema 使用不同策略
const schema2 = d.camelCase.schema("schema2");
const orders = schema2.table("orders", {
  orderId: d.serial().primaryKey(),     // orderId
  totalAmount: d.real(),                // totalAmount
});

这个改动逻辑清晰，但属于 breaking change。如果你的项目里用了旧版 casing helper，升级到 rc.1 之前需要完整过一遍官方迁移文档。

2.4 Drizzle for LLM Agents（预览阶段）

这是一个面向 AI 时代的探索性功能，目前还在 preview 阶段。

目标很简单：让 LLM Agent 能够直接理解和操作 Drizzle 管理的数据库 Schema。目前的实现方式是通过 drizzle-orm@ai 分支，提供：

结构化的 Schema 导出（给 LLM 读取的数据库结构描述）
自然语言到 SQL 的辅助生成（基于 Schema 上下文）

对于构建 AI-native 应用（AI 数据分析助手、AI 数据库管理员）的团队，这是一个值得关注的方向。不过目前还处于早期阶段，建议先用官方 Discord 联系团队了解具体实现细节。

三、Bun SQL：为什么 Bun 能提供零拷贝数据库访问

理解了 JIT Row Mappers 之后，有必要单独说一下 Bun SQL 的底层优化，因为两者是互相成就的关系。

3.1 Bun 内置 SQL 的技术优势

Bun 从 v1.0 开始就内置了 SQLite 支持（bun:sqlite），在 v1.3.x 版本中对 PostgreSQL、MySQL 的支持也已经相当成熟。Bun SQL 的性能优势来自以下几个层面：

第一层：JavaScriptCore vs V8

Node.js 使用 V8 引擎，Bun 使用 JavaScriptCore（JSC）。JSC 在某些特定场景下（尤其是大量小对象创建和短期存活对象）比 V8 有更好的内存分配效率。对于 ORM 的行映射场景，JSC 的线性分配器（Linear Allocator）在处理大量 User 对象创建时比 V8 的 GC 分代收集更有优势。

第二层：原生数据库协议解析

Bun 对 PostgreSQL 的 wire protocol（版本 3.0）做了原生实现，不依赖 Node.js 的 libpq 或 pg 驱动的 JavaScript 实现层。这避免了 JavaScript/TypeScript 到原生模块之间的数据拷贝和类型转换开销。

第三层：HTTP 服务器与数据库连接的协同调度

在典型的 Web 应用中，HTTP 请求处理和数据库查询是交替进行的。Bun 的 event loop 在调度这两类 IO 时做了协同优化：当一个 HTTP 请求在等待数据库响应时，Bun 可以高效地切换到处理另一个请求，而不是像传统 Node.js 那样陷入 callback/Promise 嵌套。

四、代码实战：构建一个高性能用户服务

4.1 项目初始化

# 使用 Bun 创建项目
bun create drizzle-bun-api my-api
cd my-api

# 安装 Drizzle ORM、Bun SQL 驱动和 PostgreSQL 客户端
bun add drizzle-orm postgres
bun add -d drizzle-kit @types/pg

4.2 Schema 定义

// src/schema/users.ts
import { pgTable, serial, text, timestamp, boolean, integer } from 'drizzle-orm/pg-core';

export const users = pgTable("users", {
  id: serial("id").primaryKey(),
  email: text("email").notNull().unique(),
  fullName: text("full_name").notNull(),
  avatarUrl: text("avatar_url"),
  isActive: boolean("is_active").notNull().default(true),
  role: text("role").notNull().default('user'),
  createdAt: timestamp("created_at").notNull().defaultNow(),
  updatedAt: timestamp("updated_at").notNull().defaultNow(),
  postCount: integer("post_count").notNull().default(0),
});

export type User = typeof users.$inferSelect;
export type NewUser = typeof users.$inferInsert;

4.3 数据库连接（Bun + Bun SQL）

// src/db/index.ts
import { drizzle } from 'drizzle-orm/bun-sql';
import Database from 'bun:sqlite';
import { migrate } from 'drizzle-orm/bun-sql/migrator';
import * as schema from '../schema/users';

// 使用 bun:sqlite 内置驱动创建数据库连接
const sqlite = new Database('./data/app.db');
const db = drizzle(sqlite, { schema });

// 初始化时运行迁移
async function init() {
  await migrate(db, { migrationsFolder: './drizzle' });
  console.log('✅ Database initialized');
}

init();

export { db, schema };

4.4 使用 Bun PostgreSQL 驱动的生产配置

如果使用 PostgreSQL：

// src/db/postgres.ts
import { drizzle } from 'drizzle-orm/postgres-js';
import postgres from 'postgres';
import { migrate } from 'drizzle-orm/postgres-migrator';
import * as schema from '../schema/users';

const client = postgres({
  host: process.env.DB_HOST,
  port: 5432,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  max: 20,  // 连接池最大连接数
  idle_timeout: 20,
  connect_timeout: 10,
});

export const db = drizzle(client, { schema });

4.5 核心 CRUD 操作

// src/services/userService.ts
import { eq, desc, sql, and, like, gte } from 'drizzle-orm';
import { db, schema } from '../db';
import type { User, NewUser } from '../schema/users';

export class UserService {
  // 创建用户（JIT Row Mapper 演示：高频写入时优势明显）
  async create(data: Omit<NewUser, 'id' | 'createdAt' | 'updatedAt'>) {
    const now = new Date();
    const [user] = await db.insert(schema.users).values({
      ...data,
      createdAt: now,
      updatedAt: now,
    }).returning();
    return user;
  }

  // 按 ID 查询（配合 JIT 映射，延迟极低）
  async findById(id: number): Promise<User | undefined> {
    const result = await db.select().from(schema.users).where(eq(schema.users.id, id));
    return result[0];
  }

  // 邮箱精确查询（索引覆盖查询，极速）
  async findByEmail(email: string): Promise<User | undefined> {
    const result = await db.select().from(schema.users).where(eq(schema.users.email, email));
    return result[0];
  }

  // 分页查询 + 排序（JIT 映射在批量读取时优势最大）
  async findPaginated(page: number, pageSize: number) {
    const offset = (page - 1) * pageSize;
    
    const [data, countResult] = await Promise.all([
      db.select().from(schema.users)
        .orderBy(desc(schema.users.createdAt))
        .limit(pageSize)
        .offset(offset),
      db.select({ count: sql<number>`count(*)` }).from(schema.users),
    ]);

    return {
      data,
      total: Number(countResult[0].count),
      page,
      pageSize,
      totalPages: Math.ceil(Number(countResult[0].count) / pageSize),
    };
  }

  // 复杂条件查询（AND/OR 组合）
  async search(filters: {
    role?: string;
    isActive?: boolean;
    createdAfter?: Date;
    namePattern?: string;
  }) {
    const conditions = [];
    
    if (filters.role) {
      conditions.push(eq(schema.users.role, filters.role));
    }
    if (filters.isActive !== undefined) {
      conditions.push(eq(schema.users.isActive, filters.isActive));
    }
    if (filters.createdAfter) {
      conditions.push(gte(schema.users.createdAt, filters.createdAfter));
    }
    if (filters.namePattern) {
      conditions.push(like(schema.users.fullName, `%${filters.namePattern}%`));
    }

    return db.select().from(schema.users)
      .where(conditions.length > 0 ? and(...conditions) : undefined)
      .orderBy(desc(schema.users.createdAt));
  }

  // 原子递增（常用于计数器更新，如帖子数、点赞数）
  async incrementPostCount(userId: number) {
    const [updated] = await db.update(schema.users)
      .set({
        postCount: sql`${schema.users.postCount} + 1`,
        updatedAt: new Date(),
      })
      .where(eq(schema.users.id, userId))
      .returning();
    return updated;
  }
}

export const userService = new UserService();

4.6 性能基准测试脚本

// benchmark/benchmark.ts
import { db, schema } from '../src/db';
import { sql } from 'drizzle-orm';
import { userService } from '../src/services/userService';

async function runBenchmark() {
  // 准备测试数据
  console.log('📊 准备测试数据...');
  const testUsers = Array.from({ length: 100 }, (_, i) => ({
    email: `bench-user-${i}@example.com`,
    fullName: `Benchmark User ${i}`,
    isActive: true,
    role: i % 3 === 0 ? 'admin' : 'user',
    postCount: 0,
  }));
  
  await db.insert(schema.users).values(testUsers).onConflictDoNothing();
  
  // 测试 1: 单条精确查询延迟
  console.log('\n📍 测试 1: 单条精确查询 (1000次平均)');
  const queryTimes: number[] = [];
  for (let i = 0; i < 1000; i++) {
    const start = performance.now();
    await db.select().from(schema.users).where(sql`id = ${i % 100}`);
    queryTimes.push(performance.now() - start);
  }
  const avgQuery = queryTimes.reduce((a, b) => a + b, 0) / queryTimes.length;
  const p99Query = queryTimes.sort((a, b) => a - b)[Math.floor(queryTimes.length * 0.99)];
  console.log(`   平均延迟: ${avgQuery.toFixed(2)}ms | P99: ${p99Query.toFixed(2)}ms`);

  // 测试 2: 批量读取（500条）
  console.log('\n📍 测试 2: 批量读取 500 条记录');
  const batchStart = performance.now();
  const batchResult = await db.select().from(schema.users).limit(500);
  const batchTime = performance.now() - batchStart;
  console.log(`   读取 ${batchResult.length} 条 | 耗时: ${batchTime.toFixed(2)}ms | 吞吐量: ${(batchResult.length / batchTime * 1000).toFixed(0)} records/sec`);

  // 测试 3: 写入性能
  console.log('\n📍 测试 3: 批量写入 100 条');
  const writeStart = performance.now();
  await db.insert(schema.users).values(
    Array.from({ length: 100 }, (_, i) => ({
      email: `batch-${Date.now()}-${i}@test.com`,
      fullName: `Batch User ${i}`,
      isActive: true,
      role: 'user',
      postCount: 0,
    }))
  );
  const writeTime = performance.now() - writeStart;
  console.log(`   写入 100 条 | 耗时: ${writeTime.toFixed(2)}ms | 吞吐量: ${(100 / writeTime * 1000).toFixed(0)} writes/sec`);
}

runBenchmark().catch(console.error);

五、生产落地：迁移指南与避坑总结

5.1 从 Prisma 迁移到 Drizzle

如果你的项目目前在用 Prisma，想迁移到 Drizzle，下面是核心差异对比和迁移步骤：

维度	Prisma	Drizzle
Schema 定义	`schema.prisma` 专属 DSL	TypeScript 代码
类型生成	单独 `prisma generate`	自动推导 `InferSelectModel`
迁移工具	`prisma migrate` / `prisma db push`	`drizzle-kit`
运行时体积	~4MB (含 Prisma 运行时)	~50KB
Edge 支持	部分支持	完整支持
关联查询语法	Prisma 专属 DSL	SQL-like `join()` 方法
事务支持	`prisma.$transaction`	`db.transaction(callback)`

迁移步骤（以 PostgreSQL 为例）：

# 1. 安装 Drizzle 相关包
bun add drizzle-orm postgres
bun add -d drizzle-kit

# 2. 编写 Drizzle Schema（对照 Prisma schema）
// drizzle/schema/users.ts
import { pgTable, serial, text, boolean, timestamp, integer } from 'drizzle-orm/pg-core';

export const users = pgTable("users", {
  id: serial("id").primaryKey(),
  email: text("email").notNull().unique(),
  fullName: text("full_name").notNull(),
  isActive: boolean("is_active").notNull().default(true),
  createdAt: timestamp("created_at").notNull().defaultNow(),
});

// 3. 配置 drizzle.config.ts
import { defineConfig } from 'drizzle-kit';

export default defineConfig({
  schema: './src/schema/index.ts',
  out: './drizzle',
  dialect: 'postgresql',
  dbCredentials: {
    url: process.env.DATABASE_URL!,
  },
});

// 4. 生成迁移文件
npx drizzle-kit generate

// 5. 应用迁移
npx drizzle-kit migrate

Prisma → Drizzle 核心 API 对照：

// Prisma 写法
const user = await prisma.user.findUnique({
  where: { id: 1 },
  include: { posts: true },
});

// Drizzle 写法（显式关联查询）
const user = await db.query.users.findFirst({
  where: eq(users.id, 1),
  with: { posts: true },
});

不过需要注意：Drizzle 的 with 关联语法需要你在 Schema 中明确定义 relations：

import { relations } from 'drizzle-orm';
import { posts } from './posts';

export const usersRelations = relations(users, ({ many }) => ({
  posts: many(posts),
}));

5.2 Drizzle + Bun 在生产环境中的注意事项

连接池配置（Bun + PostgreSQL）：

// ❌ 错误：没有配置连接池限制
const client = postgres(process.env.DATABASE_URL);

// ✅ 正确：根据并发量配置连接池
const client = postgres({
  url: process.env.DATABASE_URL,
  max: Math.min(20, Number(process.env.DB_MAX_CONNECTIONS) || 10),
  idle_timeout: 30,
  ssl: process.env.NODE_ENV === 'production' ? { rejectUnauthorized: false } : false,
});

Bun 生产环境数据库连接池配置原则：

max：建议设置为 CPU 核心数 × 4，对于 Bun 这种高并发运行时，通常 10-20 足够了
idle_timeout：生产环境建议 20-30 秒，避免长时间空闲连接占用数据库资源
始终配置 SSL：生产环境数据库连接必须启用 TLS

迁移踩坑清单（casing API breaking change）：

// ❌ 旧版写法（rc.1 不支持）
const users = pgTable("users", {
  fullName: text("full_name").$type<string>(),
});

// ✅ 新版写法（统一使用 snakeCase 策略）
import { snakeCase } from 'drizzle-orm/pg-core';

const users = snakeCase.table("users", {
  fullName: text(),  // 自动映射到 full_name 列
  createdAt: timestamp(),  // 自动映射到 created_at 列
});

// 如果需要混合策略（部分表 camelCase、部分 snake_case）：
const usersTable = pgTable("users", { ... }, (table) => ({
  // 在映射函数中自定义
}));

5.3 什么时候该选 Drizzle + Bun，什么时候不该

适合的场景：

边缘计算 / Serverless：Drizzle 体积小、零依赖，兼容 Cloudflare Workers、Vercel Edge Runtime、Deno Deploy
轻量 API 服务：用 Hono + Drizzle + Bun 的组合，构建一个高性能 API 服务，bundle 体积可能不到 200KB
TypeScript-first 团队：团队已经大量使用 TypeScript，希望数据库操作也享受同等的类型安全
性能敏感的服务端场景：高并发、低延迟的 API 网关、游戏后端、实时数据管道
多数据库支持：同一套 Schema 可以同时支持 PostgreSQL、MySQL、SQLite、Better-SQLite3

不适合的场景：

复杂关联和动态查询：如果你的业务需要大量动态构建复杂查询（条件随意组合、动态排序字段等），Prisma 的 query builder 在这类场景下更成熟
大型团队、文档驱动：Prisma 的文档和社区生态更成熟，团队新人上手成本更低
需要实时订阅：Prisma 支持数据库事件订阅（prisma.$subscribe），Drizzle 目前没有对等的方案
非 TypeScript 项目：Python、Go、Rust 团队，Drizzle 完全不适用

六、Drizzle 与 Prisma：四年后的格局变化

Drizzle 官方在发布 v1.0.0-rc.1 的推文里，顺带提了一句 Prisma："4 years in，Drizzle is still just doing Drizzle. 8 years in，Prisma is doing whatever they can to stay?"

这句话在社区引发了激烈讨论。

6.1 Prisma 的困境

Prisma 在 2019-2022 年间是 TypeScript ORM 的绝对标杆，但近年来面临几个结构性挑战：

性能与体积的矛盾：Prisma 6/7 在持续增加功能的同时，运行时体积也在膨胀。对于只需要执行几条 SQL 的边缘函数来说，Prisma 的启动代价太大了。

路线分歧：Prisma 尝试往"数据平台"方向演进，增加了数据代理、数据浏览器等周边功能，这让部分只需要一个 ORM 的开发者感到困惑。

社区信任度：随着 Prisma v7 的 breaking changes 增多，一些长期用户开始表达不满，认为升级成本太高。

6.2 Drizzle 的底气

Drizzle 能在四年内积累起足够的底气，靠的是三点：

极致的性能专注：Drizzle 团队几乎没有做"平台功能"，一直在 ORM 性能和 TypeScript 集成体验上深耕
透明的架构：没有黑盒，没有 DSL，生成的 SQL 看得见摸得着
社区的口碑传播：Hono、Elysia、Fastify 等框架社区对 Drizzle 的推荐效应非常强

七、性能深度分析：为什么 7.3ms 的延迟对现代应用意味着什么

7.1 延迟分解：一个 HTTP 请求在 Drizzle + Bun 中的完整旅程

理解 7.3ms 延迟的关键，是把它拆解成每个环节的耗时：

[DNS 解析]   0.1-0.5ms    （通常由负载均衡器缓存，可忽略）
[TCP 连接]   0.5-2ms      （Bun 保持长连接，无此开销）
[TLS 握手]   0             （内网环境）
[HTTP 请求处理] 0.5-1ms    （Bun 的 HTTP 处理，极快）
[数据库查询路由] 0.2-0.5ms  （Bun SQL 连接池查找）
[数据库执行]     1-3ms     （取决于查询复杂度）
[结果集传输]     0.5-1.5ms  （Bun SQL 零拷贝，相比 Node.js 节省 ~50%）
[JIT 映射]       0.1-0.3ms  （JIT Row Mapper，接近零开销）
[JSON 序列化]   0.3-1ms     （Bun 的 JSON 序列化极快）
─────────────────────────────
总计            ≈ 7.3ms

对比传统 Node.js + Prisma 的类似场景（不含数据库执行时间）：

[JSON 序列化]   1-3ms       （Prisma 的 JSON 序列化较慢）
[ORM 行映射]   1-5ms       （动态类型判断，传统方式）
[结果集拷贝]   0.5-2ms     （多次内存拷贝）
─────────────────────────────
额外开销        ≈ 5-10ms

两者加起来，Drizzle + Bun 比 Node.js + Prisma 在非数据库层面可能节省 5-10ms，这意味着在数据库查询本身只需要 5-10ms 的场景下，总响应时间可以从 20ms 降低到 10ms，快了整整一倍。

7.2 CPU 利用率的真相

基准测试里 Drizzle 侧 CPU 利用率 81.6% vs Go 侧 75.5%，差了约 6 个百分点。

这 6 个百分点不是浪费——它是 JIT Row Mapper 在运行时持续工作的证明。JIT 编译的映射函数虽然快，但编译和维护这个函数本身需要 CPU 周期。这是一种以 CPU 换内存和延迟的策略。

对于计算密集型工作负载（如 AI 推理、图像处理），这种 CPU 代价可能不可接受。但对于 IO 密集型的 Web API 服务，用 6% 的额外 CPU 换 60% 的延迟降低，是非常划算的买卖。

八、总结与展望

8.1 Drizzle ORM v1.0.0-rc.1 的核心价值

Drizzle ORM 用四年时间做到了最难的一件事：把"轻量"和"高性能"同时贴在自己身上。这次 v1.0.0-rc.1 带来的四大更新各有价值：

JIT Row Mappers：把 ORM 层的性能损耗从"可见的瓶颈"变成"可以忽略的噪音"，这是技术层面的真正突破
Effect v4 集成：为函数式编程爱好者提供了完整的类型安全数据库操作方案
Casing API 重构：解决了历史债务，让命名策略更清晰可控（代价是迁移成本）
LLM Agent 支持：面向未来的探索性布局

8.2 对 TypeScript 服务端开发者的意义

Drizzle + Bun 的组合，在 2026 年已经证明了一个重要命题：TypeScript 在服务端性能上，已经具备了和 Go 正面竞争的实力——至少在 Web API 这个赛道上。

这意味着前端开发者可以真正用同一门语言（同构到全栈）构建高性能服务端应用，而不需要为了性能被迫切换到 Go/Rust。这对整个 TypeScript 生态都是利好。

8.3 建议的技术跟进路线

如果你正在启动新项目：认真考虑 Drizzle + Bun 或 Drizzle + Hono 组合，这是目前 TypeScript 服务端开发的"性能天花板"配置
如果你在用 Prisma：评估当前迁移成本，如果 Schema 不复杂且没有深度依赖 Prisma 特有功能，可以计划在 v1.0 正式版发布后迁移
如果你是性能优先的场景：在生产环境做一次真实的对比基准测试——用自己的业务查询、自己的数据规模、自己的数据库配置，而不是只看官方宣传数据

2026 年的 Drizzle ORM v1.0，已经不只是一个"轻量 ORM 选项"，它正在成为 TypeScript 服务端高性能开发的事实标准之一。

参考链接：

Drizzle ORM 官方文档：https://orm.drizzle.team
Drizzle GitHub：https://github.com/drizzle-team/drizzle-orm
Bun 官方文档：https://bun.sh
Bun SQL 模块：https://bun.sh/docs/api/sql
Effect 官方文档：https://effect.website