Hono ORM 框架推荐：Drizzle、Prisma、Kysely、TypeORM 怎么选

Hono 项目选 ORM，不能只看哪个最火。

真正要看的是：

1
2
3
4
5

你部署在哪里？
你用什么数据库？
你要不要边缘运行时？
你更在意类型安全，还是开发体验？
你能不能接受生成代码和额外 runtime？

Hono 很轻，它不会规定你必须用哪一个 ORM。这是好事，但也意味着你要自己判断。

如果选错，后面会出现很尴尬的问题：

1
2
3
4

本地 Node.js 能跑，上 Cloudflare Workers 跑不了
ORM 很舒服，但边缘环境不支持连接池
类型推断很好，但迁移流程没人会维护
查询写起来优雅，但生产慢查询查不出来

这篇文章先做一次 Hono ORM 选型。后面几篇再分别写 Hono + ORM + D1、SQLite、MySQL、PostgreSQL 的具体落地。

技术栈快照时间：2026-06-23。Hono、Drizzle、Prisma、Kysely、Cloudflare D1 生态变化很快，具体版本和配置以官方文档为准。

一、先给结论

如果你用 Hono + Cloudflare Workers + D1：

1

优先选 Drizzle ORM

原因很简单：Drizzle 对 D1 支持自然，schema 写法接近 SQL，运行时轻，适合边缘环境。

如果你用 Hono + SQLite 做本地工具、小型后台、单机服务：

1

Drizzle 或 Kysely

Drizzle 更像轻量 ORM，schema、迁移、查询体验一体化。Kysely 更像类型安全 SQL builder，适合你不想要完整 ORM，只想把 SQL 写得更安全。

如果你用 Hono + MySQL：

1

Drizzle 或 Prisma

小团队、Serverless、想轻一点，选 Drizzle。传统业务系统、团队熟悉 Prisma、想要 Prisma Studio 和成熟数据模型体验，可以选 Prisma。

如果你用 Hono + PostgreSQL：

1

Drizzle、Prisma、Kysely 都能选

PostgreSQL 能力很强，选择取决于你团队的口味。想轻量、类型安全、贴近 SQL，选 Drizzle。想要成熟 ORM 体验，选 Prisma。想精细控制 SQL，选 Kysely。

TypeORM 我现在一般不会作为 Hono 新项目首选。不是不能用，而是 Hono 项目通常追求轻量和明确边界，TypeORM 的装饰器、实体生命周期、历史包袱不一定划算。

二、快速对比表

我自己的默认推荐是：

1
2
3
4

Hono + D1         -> Drizzle
Hono + SQLite     -> Drizzle / Kysely
Hono + MySQL      -> Drizzle / Prisma
Hono + PostgreSQL -> Drizzle / Prisma / Kysely

如果你不想纠结，就先选 Drizzle。

它和 Hono 的气质比较像：轻、TypeScript 友好、不会把业务代码拖进一个很重的框架世界。

三、为什么 Drizzle 很适合 Hono

Hono 的特点是轻。

Drizzle 的特点也是轻。

你不会写一堆装饰器，也不需要启动一个庞大的 ORM runtime。schema 就是 TypeScript：

1
2
3
4
5
6
7

import { sqliteTable, text, integer } from 'drizzle-orm/sqlite-core'

export const users = sqliteTable('users', {
  id: integer('id').primaryKey({ autoIncrement: true }),
  email: text('email').notNull().unique(),
  name: text('name').notNull(),
})

查询也比较接近 SQL：

1
2
3
4
5

const user = await db
  .select()
  .from(users)
  .where(eq(users.email, email))
  .get()

这对 Hono 项目很重要。

因为 Hono 经常跑在这些环境：

• Cloudflare Workers
• Cloudflare Pages Functions
• Node.js
• Bun
• Deno
• Serverless

你不一定总是有传统长连接环境，也不一定适合使用很重的 ORM runtime。

Drizzle 的优势是：它不替你假装数据库很简单，但它能把类型、schema、迁移和查询组织得更清楚。

四、Prisma 适合什么情况

Prisma 的开发体验很好。

你可以写 schema：

1
2
3
4
5
6

model User {
  id        String   @id @default(cuid())
  email     String   @unique
  name      String
  createdAt DateTime @default(now())
}

然后生成 client：

1

pnpm prisma generate

查询：

1
2
3

const user = await prisma.user.findUnique({
  where: { email },
})

这套体验很完整，尤其适合团队项目和传统 Node.js 后端。

但在 Hono 项目里要注意两点。

第一，运行环境。

如果你跑在普通 Node.js 服务上，Prisma 很自然。如果你跑在 Cloudflare Workers、边缘运行时、Serverless，需要确认对应 adapter、driver、连接方式是否符合当前官方支持。

第二，抽象成本。

Prisma 很舒服，但它也会把你的数据库访问方式带进 Prisma 的世界。简单 CRUD 很爽，复杂 SQL、特殊索引、窗口函数、数据库原生能力，还是要理解 SQL。

我的建议是：

1
2

传统 Node.js Hono 后端，可以认真考虑 Prisma。
Cloudflare Workers / D1 项目，不要默认上 Prisma，先看 Drizzle。

五、Kysely 适合什么情况

Kysely 不是传统 ORM。

它更像类型安全 SQL query builder。

你会写：

1
2
3
4
5

const user = await db
  .selectFrom('users')
  .select(['id', 'email', 'name'])
  .where('email', '=', email)
  .executeTakeFirst()

它的优势是 SQL 控制感强。

如果你团队里有人本来就熟 SQL，不想被 ORM 的 relation、entity、model 绑住，Kysely 会很舒服。

缺点是你要自己管理更多东西：

• schema 类型
• migration 工具
• repository 规范
• 数据转换
• 关系查询组织方式

所以 Kysely 更适合对 SQL 有要求的团队，而不是完全想靠 ORM 屏蔽数据库的人。

六、TypeORM 为什么不首推

TypeORM 不是不能用。

很多项目还在用，也能跑。

但如果今天从零写一个 Hono 项目，我不会优先推荐 TypeORM。

原因有几个：

1
2
3
4
5

它更偏传统 ORM
装饰器和实体模型侵入性更强
运行时更重
和 Hono 的轻量风格不完全一致
边缘运行时不是它的主战场

如果你已经有 TypeORM 项目，没必要为了追新强行迁移。

但新项目，尤其是 Hono + Serverless / Edge，我会优先看 Drizzle 或 Kysely。

七、ORM 不应该进入 route 层

无论你选哪个工具，都不要让 ORM 直接污染 HTTP 层。

不要长期写成这样：

1
2
3
4
5
6
7

app.get('/api/users/:id', async (c) => {
  const user = await db.query.users.findFirst({
    where: eq(users.id, c.req.param('id')),
  })

  return c.json({ data: user })
})

更推荐：

1

route -> service -> repository -> ORM / SQL

route：

1
2
3
4

usersRoute.get('/:id', async (c) => {
  const user = await userService.getProfile(c.req.param('id'))
  return c.json({ data: user })
})

repository：

1
2
3
4
5
6
7

export async function findUserById(id: string) {
  return db
    .select()
    .from(users)
    .where(eq(users.id, id))
    .limit(1)
}

这样以后你从 Drizzle 换 Prisma，或者从 SQLite 换 PostgreSQL，影响范围不会扩散到所有 route。

八、不要以为 ORM 可以替代 SQL

ORM 最容易制造一个错觉：

1

我不用懂数据库了。

这是错的。

你仍然要理解：

• 主键
• 唯一索引
• 外键
• 事务
• 连接池
• N+1 查询
• 分页
• 慢查询
• 迁移
• 备份

ORM 只是帮你组织代码，不是替你做数据库设计。

尤其是 Hono + PostgreSQL / MySQL 这类生产项目，连接池和索引非常关键。

尤其是 Hono + D1，D1 是 SQLite 语义，但部署在 Cloudflare 平台上，有自己的限制和适合场景。不要把它当成无限扩展的传统大型数据库。

九、我的最终建议

如果你要一句话：

1

Hono 新项目，优先从 Drizzle 开始。

更细一点：

1
2
3
4

D1：Drizzle
SQLite：Drizzle 或 Kysely
MySQL：Drizzle；团队偏传统可选 Prisma
PostgreSQL：Drizzle；复杂 SQL 多可选 Kysely；团队重 DX 可选 Prisma

但不管选什么，都要守住边界：

1
2
3
4
5

Hono 负责 HTTP
Service 负责业务
Repository 负责数据访问
ORM 只待在 repository 附近
SQL 能力不能丢

这才是 Hono + ORM 最舒服的写法。

参考资料

• Hono 官方文档
• Drizzle ORM 官方文档
• Drizzle D1 文档
• Prisma 官方文档
• Kysely 官方文档
• Cloudflare D1 文档