2026-10-13
· Dylan YuPrisma Studio 替代品：面向 Prisma、Drizzle 和 Kysely 的数据库 GUI
Prisma Studio 和 Drizzle Studio 是出色的内置数据浏览器，但它们是为拥有 schema 的开发者打造的。当你需要把数据展示给队友时，这里有替代方案。
如果你使用一个 TypeScript ORM，你很可能没开口就免费得到了一个数据库 GUI。Prisma 附带了 Prisma Studio。Drizzle 附带了 Drizzle Studio。你运行一条命令，一个浏览器标签页打开，你的数据就在一个整洁的网格里，你可以点进去编辑。这确实是个好东西，在项目的很长一段时间里，它会是你会打开的唯一数据库工具。
然后一件小事发生了，模型就崩了。一个队友要求看看新的注册用户。你的设计师想知道哪些记录缺了缩略图。你的联合创始人想了解一下有多少订单卡在待处理状态。他们都不想运行 npx prisma studio 去眯着眼看外键。他们想要一个视图——一个他们能读的网格、一块他们能拖动的看板、一张他们能扫一眼的图表——而这些内置工具从来就不是为了把视图交给他们而构建的。
这篇文章讲的就是那个时刻。我用过 Prisma Studio 和 Drizzle Studio，我自己也构建了一个数据库工具（BaseVolt），所以我不是中立的观察者。但重点不是告诉你内置工具不好——而是诚实地说明它们是干什么用的、在哪里开始不再有用，以及当你已经用不下它们时，现实的替代方案长什么样。
内置的 studio 工具究竟是干什么用的
让我先给 studio 工具它们应得的肯定，因为很多"替代品"文章直接跳到批评，那既不公平也没帮助。
Prisma Studio 是一个本地 web 应用，针对你的数据库运行，由你的 Prisma schema 驱动。你启动它，它读取你的模型，给你一个 UI，你可以在其中浏览每张表的行并编辑它们。它几乎完全面向检查和编辑行：你选一个模型，看到一张分页的记录表，点一个单元格，改一个值，保存。对于一个因为自己写了 schema 所以了解 schema 的开发者，这接近理想。没有要费心的连接配置，也没有要等待的 schema 内省。ORM 已经知道一切，所以工具也已经知道一切。
Drizzle Studio 对 Drizzle 项目是同样的思路。它是一个内置的数据浏览器，读取你的 Drizzle schema，给你一个本地 UI 来浏览和编辑它背后的数据。如果你是 Drizzle 用户，你得到可比的体验：启动它、打开一个标签页、点过你的表、编辑一行。
那 Kysely 呢？Kysely 是一个查询构建器，不是一个拥有 schema 优先数据模型的完整 ORM，它不附带第一方 GUI。这不是贬低——查询构建器的工作是构建类型安全的 SQL，而它做得很好——但这意味着如果你是 Kysely 用户，根本没有任何内置的 studio 工具。你本来就得伸手去拿一个单独的数据库客户端。
所以这三者的规律是：内置工具之所以存在，是因为 ORM 已经持有一份机器可读的 schema 描述，而 studio 工具是把那份描述变成可点击 UI 的最廉价方式。它让 ORM 维护者几乎不花成本就能附带，让你零成本使用，并且把"我需要装一个数据库 GUI"这一步从早期开发中彻底移除。
它们做得好的地方
内置工具擅长一项特定、狭窄、常见的工作：开发过程中的快速行级编辑。 你在构建一个功能，你填充了一些数据，某个东西看起来不对，你想看看实际的那一行并修好它。Prisma Studio 和 Drizzle Studio 对此很完美。它们离你只有一条命令，它们理解你的关系，而且除了你已经有的东西之外，它们不需要任何设置。
它们也擅长 schema 形状的浏览。 因为工具知道你的模型，它可以用你的应用思考数据的方式来呈现你的数据，而不是数据库的方式。如果你有一个带 posts 关系的 User 模型，studio 可以直接给你展示那个关系，而一个通用 SQL 客户端会让你写一个 join 才能看到同样的东西。而且它们免费——没有许可证、没有席位成本、没有会过期的试用——这对独立开发者或小团队很重要。
模型在哪里崩坏
这是诚实的那部分。内置工具围绕一个假设构建，而这个假设在你的项目成长到超出你一个人的那一刻就不再成立：假设唯一看数据的人就是写 schema 的人。
它们从构造上就是面向开发者的。 要使用 Prisma Studio 或 Drizzle Studio，你得在终端里运行一条命令，并理解你 ORM 的模型。你不可能把一个终端和一条 npx 调用交给一个非技术队友。工具整个访问模型是"你已经有了仓库和工具链"——对你来说没问题，对其他人来说是一堵墙。
它们是单用户的。 一个 studio 工具在你的机器上运行、针对你的数据库、为你的会话服务。它不是一个共享面：没有邀请队友、把他们限制在一张表，或者给某人一个只读视图。
它们是网格，不是视图。 一个 studio 工具给你一张行表。它不会给你针对图片表的画廊、针对带状态列的表的 kanban 看板，或者带图表的 dashboard。如果你的队友问"哪些订单卡住了？"，一个行网格在技术上正确但无用武之地地回答了它——他们得读每一行，并在脑子里记住状态。一个看板视图能瞬间回答它，而内置工具没有看板。
这些都不是 bug。它是这些工具之所是的自然结果：一个覆盖在你已有 schema 之上的薄而方便的 UI，直指拥有那份 schema 的开发者。问题是，大量需要数据库 GUI 的人并不是那个开发者。
ORM 无关 vs ORM 耦合
在讲替代品之前，先讲一个能让整个版图变得清晰的框架。这个领域的每个工具都落在 ORM 耦合和 ORM 无关之间的一个谱系上，而一个工具坐在哪一边，几乎决定了它行为的一切。
一个 studio 工具是 ORM 耦合的。 它通过你的 ORM 了解你的 schema。Prisma Studio 读 Prisma 的 schema；Drizzle Studio 读 Drizzle 的 schema。这种耦合既是它最大优势的来源——即时设置、schema 感知的浏览、免费的关系——也是它最大局限的来源。因为工具只通过你的 ORM 理解世界，所以它只在你处于 ORM 的世界里时才工作。它需要你的仓库、你的 schema 文件、你的工具链，而且它只知道你的 ORM 暴露的东西：你应用的模型，不一定整个数据库。
一个数据库 GUI 是 ORM 无关的。 它通过一个标准协议、使用一个连接字符串，与数据库本身通信。它不在乎你的应用用的是 Prisma、Drizzle、Kysely、裸 SQL，还是什么都没有；它直接内省数据库。这种解耦是它灵活性的来源：无论你的应用是一个 TypeScript ORM 项目、一个 Rails 应用、一个 Go 服务，还是你从一个离职的人那里继承来的数据库，它都以同样的方式工作。
这是关键的区分，而且它有一个实际的后果。一个数据库 GUI 在你接触的每个项目和每个 ORM 上给你一个一致的界面。 如果你在三个服务上工作，它们有三个不同的数据层，一个 ORM 耦合的工具意味着三条 studio 命令和三个 UI。一个 ORM 无关的工具意味着一个应用、一个界面，指向三个连接字符串。它还意味着更微妙的东西，而这一点在这里很重要：一个 ORM 无关的工具能展示你的 ORM 没有建模的数据。 每份 ORM schema 都是数据库的一个精挑细选的子集——有些表你的 Prisma schema 不包含，有些列你的 Drizzle 模型不声明，还有些视图和连接表只存在于数据库里。一个数据库 GUI 看到整个数据库，因为它在看数据库。
有一个权衡，我会诚实地说明它：ORM 无关的工具不会免费获得 schema 感知。一个 studio 工具知道你的关系，因为你的 ORM 告诉了它。一个通用 GUI 必须通过内省外键来发现关系，这效果不错，但不等于理解你的模型。有些 GUI 工具在这方面已经做得很好——外键可视化、自动关系检测——但重点依然成立：耦合买到便利，解耦买到普适。
记住这个谱系，因为它解释了为什么下面的替代品是这样分组的。Prisma Studio 和 Drizzle Studio 坐在耦合的那一端。DBeaver、TablePlus 和 BaseVolt 坐在无关的那一端。
替代品
让我逐一过一遍现实的选项。我会具体说明每一个擅长什么、在哪里不足，以及谁应该选它——包括内置工具本身，因为在很多情况下正确的答案是继续使用它们。
Prisma Studio（说实话，留着它）
把 Prisma Studio 列为它自己的替代品可能看起来奇怪，但对"我该用什么替换 Prisma Studio？"最常见的正确答案是"暂时什么都不用换"。
它是什么： 随 Prisma 附带的内置数据浏览器。它在本地运行，读取你的 Prisma schema，给你一个浏览和编辑行的 UI。Prisma Studio 免费，离你只有一条命令。
它擅长什么： 开发过程中的快速、schema 感知的行编辑。因为它由你的 Prisma schema 驱动，它开箱即理解你的模型及其关系，而且完全不需要设置。对一个修复坏行或检查 seed 脚本产出了什么的 Prisma 开发者，它差不多是数据库工具能做到的最无摩擦的。
它在哪里不足： 它耦合于 Prisma，所以只在 Prisma 项目里工作，而且它只知道你的 Prisma schema 建模的东西。它面向开发者——你需要仓库和工具链才能运行它——而且它是单用户的，所以没有办法把一个受限视图交给队友。它是一个行网格，所以没有画廊、kanban 或 dashboard 视图，也没有共享面。
谁应该选它： 任何主要需要在开发过程中检查和编辑行、而且还不需要和非技术人员共享数据的 Prisma 开发者。如果那就是你，继续用 Prisma Studio 不是妥协；这是正确的选择。
Drizzle Studio
它是什么： 面向 Drizzle 项目的对等内置数据浏览器。它读取你的 Drizzle schema，给你一个本地 UI 来浏览和编辑数据。官方细节在 Drizzle Studio overview。
它擅长什么： Prisma Studio 擅长的东西，但面向 Drizzle 用户：在你自己的项目里零设置、schema 感知的浏览和行编辑。如果你是一个只想看看自己数据的 Drizzle 开发者，它是最省力的路径，而且不花一分钱。
它在哪里不足： 和 Prisma Studio 一样的结构性局限，具体是耦合于 Drizzle。它只在 Drizzle 项目里工作，它面向开发者且是单用户的，而且它是一个网格而不是一组视图——没有画廊、kanban 或 dashboard 层，也没有办法给队友访问。
谁应该选它： 开发过程中需要快速行级访问、不需要共享数据的 Drizzle 开发者。和 Prisma Studio 一样的逻辑：如果那是你的处境，继续用它。
DBeaver
它是什么： DBeaver 是通用的、ORM 无关的数据库客户端——通过 JDBC 驱动连接基本上每个数据库引擎的工具。它是一个历史悠久、功能密集的桌面应用，其社区版免费且开源。
它擅长什么： 对写 SQL 的人来说，是广度和深度。它支持范围巨大的数据库，有一个带自动补全的完整 SQL 编辑器、schema 浏览、ER 图，以及数据导入/导出。如果你接触多种数据库引擎、想要一个应用通吃它们，DBeaver 接近无法击败。而且因为它是 ORM 无关的，它不在乎你的应用是一个 Prisma 项目——它直接连接数据库。如果你在把它和一个以 Prisma 为中心的工作流做权衡，我们的 DBeaver 对比讲得更深。
它在哪里不足： 它是一个 IDE 形状的工具，为写 SQL 的人构建，不是为了把数据当作共享面来处理。它是一个 JVM 应用，而且感觉就是：密集的面板、嵌套的工具栏，以及一条学习曲线。它围绕查询编辑器构建——你写 SQL，你得到一个网格——它不会给你一个非技术队友能用的面向业务的视图。没有 kanban、没有画廊、没有你会交给同事的 dashboard，也没有办法在不把 SQL 客户端交给某人的情况下，给他们对几个字段的受限访问。
谁应该选它： 整天写 SQL、想要一个客户端跨越多种数据库引擎、而且不需要把数据放到非技术人员面前的开发者。对那项工作它很出色，而我写了一整篇文章讲它在 DBeaver 替代品里如何对比。
TablePlus
它是什么： TablePlus 是一个面向 macOS 和 Windows 的现代、原生数据库客户端。它从一个快速、干净的应用支持范围广泛的数据库——PostgreSQL、MySQL、SQLite、SQL Server 等等。
它擅长什么： 感觉良好的日常 SQL 工作。它启动快，UI 整洁，浏览一张表或微调一行很愉快，是 JVM 应用很少能做到的那种愉快。它是 ORM 无关的，所以无论你的应用用什么和它通信，它都直接连接你的 PostgreSQL、MySQL 或 SQLite 数据库。如果你的需求是"打开一个连接、看看一张表、跑个查询、继续走"，TablePlus 做得和任何东西一样好。
它在哪里不足： 它是一个 SQL 客户端，不是管理面板。没有 kanban、画廊或 dashboard 视图，也没有办法把一个安全、受限的视图交给非技术队友。它假定你对 SQL 自在，而它的付费许可证是按席位计算的成本，对团队来说会累加。要看深入的正面对决，见我们的 TablePlus 对比。
谁应该选它： 想要一个快速、原生、通用 SQL 客户端、不需要面向业务视图的开发者。如果你是一个 Prisma 或 Drizzle 开发者，想要一个比内置 studio 更好、与 ORM 无关的客户端，TablePlus 是一个强有力的选择。
BaseVolt
这是我自己构建的那个，所以请带上通常的怀疑。我会像对其他一切一样诚实地说明它的局限。
BaseVolt 是一个面向 macOS（Apple Silicon）和 Windows 的本地优先桌面应用。它直接连接 PostgreSQL、MySQL、SQLite 和 Cloudflare D1——外加说这些协议的云服务，比如 Supabase。关键是，它是 ORM 无关的：它连接数据库本身，所以无论你的应用用的是 Prisma、Drizzle、Kysely、裸 SQL，还是什么都没有，它都以完全一样的方式工作。你下载它，连接一个数据库，大约三秒钟就得到一个可用的 dashboard。凭据在本地加密，它离线可用，你的数据永远不会离开 localhost。
它和上面那些 SQL 客户端的区别在于，它是一个管理面板，而不只是一个查询网格。一旦连接，你就在数据之上得到网格、画廊、kanban 和 dashboard 视图，内置关系和主外键可视化。它从设计上就是非破坏性的：你可以重命名字段、格式化值、为了展示连接表，而不改动你的 schema。还有一个由 AI 驱动的设置步骤，用一个 LLM 自动检测你的 schema 和关系——这是最接近内置 studio 工具给你的"工具就是知道我的模型"那种感觉的东西，只不过它对任何数据库都有效。
我用得最多的部分是内置的 MCP 服务器，它运行在 localhost 上，让你把 Claude Desktop、Cursor、Windsurf 或 Codex 指向你的数据库，让 AI 查询它。对一个 Prisma 或 Drizzle 开发者来说，这是自然的契合：你的 AI 编辑器已经通过你的 ORM 了解你的 schema，现在它也能看到实际数据了。
它擅长什么： 你想要真正的管理面板视图又不想运行服务器的本地优先数据库工作，而且你想要一个一致的界面，不管每个项目用的是哪个 ORM。如果你是独立开发者或小团队，BaseVolt 给你网格/画廊/kanban/dashboard 体验，否则你只能从一个托管工具得到，同时保持一切本地。
它在哪里不足： 它是一个桌面应用，不是共享的 web 服务——如果十几个人需要在浏览器里打开同一个面板，那么自托管的 web 选项才更合适。免费档限于两个数据源，足够认真试用，但如果你要摆弄十几个数据库就不够；Pro 是 $99/年，增加 webhooks 和动作按钮，有 14 天试用且无需信用卡。而且它在数据库支持上比 DBeaver 窄——Postgres、MySQL、SQLite 和 D1，而不是长长的引擎长尾。我不会假装不是这样。
谁应该选它： 想要一个带面向业务视图的本地优先、ORM 无关的管理面板、并且在意的数据永远不会离开机器的开发者和一个小团队。你可以在功能页面看到完整功能集，或者在安装任何东西之前逛逛在线演示。
对比表
以下是这五个的对比。表格会抹平细微差别，所以我会在下面加注。
| 工具 | 耦合于 ORM？ | 平台 | 给非技术用户的视图 | 最适合 |
|---|---|---|---|---|
| Prisma Studio | 是——仅 Prisma | macOS、Windows、Linux（本地 web 应用） | 否——只有行网格 | 在 Prisma 项目里开发过程中的快速、schema 感知的行编辑 |
| Drizzle Studio | 是——仅 Drizzle | macOS、Windows、Linux（本地 web 应用） | 否——只有行网格 | 在 Drizzle 项目里开发过程中的快速、schema 感知的行编辑 |
| DBeaver | 否——与数据库通信 | macOS、Windows、Linux | 否——查询网格和 ER 图 | 跨多种引擎的 SQL 密集、数据库无关的工作 |
| TablePlus | 否——与数据库通信 | macOS、Windows | 否——只有查询网格 | 跨多种数据库的快速、原生、日常 SQL 工作 |
| BaseVolt | 否——与数据库通信 | macOS（Apple Silicon）、Windows | 是——网格、画廊、kanban、dashboard | 在没有服务器的情况下、在任何 ORM 或没有 ORM 上的本地优先管理面板视图 |
几点说明，因为那些列隐藏了重要的区分：
- "耦合于 ORM"是第一个要决定的事。 如果你乐于在你 ORM 的世界里工作，而且只有你看数据，那么耦合的工具摩擦最小。一旦你需要跨项目看数据，或者把数据交给别人，你就想要一个 ORM 无关的工具。
- "给非技术用户的视图"才是真正的分界线。 Prisma Studio、Drizzle Studio、DBeaver 和 TablePlus 骨子里都是行网格。BaseVolt 是唯一一个整个重点就是面向非技术眼睛的网格/画廊/kanban/dashboard 层的。
- 平台和价格比人们承认的更重要。 内置 studio 工具和 DBeaver 在 macOS、Windows 和 Linux 上运行；TablePlus 是 macOS 和 Windows；BaseVolt 是 macOS（Apple Silicon）和 Windows。Prisma Studio 和 Drizzle Studio 免费且内置，DBeaver 的社区版免费且开源，TablePlus 有免费档加付费许可证，而 BaseVolt 的免费档把你限制在两个数据源。
如果你想要更深入的正面对决，我们的 DBeaver 对比和 TablePlus 对比走得更远。
什么时候 studio 工具才是正确答案
我想给这一节自己的篇幅，因为这是大多数"替代品"文章搞错的部分。有一个很大、很常见、正当的情况，内置 studio 工具不只是够用，而是最佳选项，你不应该切换。
在以下情况保留 Prisma Studio 或 Drizzle Studio：
- 你是唯一看数据的人。 如果数据永远不需要到达队友、设计师或非技术利益相关者那里，共享的论点就不适用，你只剩下设置的论点——而内置工具在这个论点上决定性地获胜。
- 你的工作是开发过程中的快速行编辑。 看看一行、修一个值、检查 seed 产出了什么。这正是 studio 工具为之构建的东西，而且没有任何东西比它更快伸手可取。
- 你深处于一个 ORM 里，不碰其他数据库。 限制 studio 工具的耦合，也正是让它毫不费力的东西。如果你做的每个项目都是 Prisma（或者每个项目都是 Drizzle），那么无关工具"一个界面跨越多个 ORM"的优势对你来说价值更低。
如果那份清单描述了你的处境，关掉这个标签页，回到 npx prisma studio。你没有错过什么。
当第二个人进入画面时，切换才值得考虑。当某个不是你的人需要看数据的那一刻——尤其当那个人不是技术人员时——内置工具就不再方便，开始成为瓶颈，因为唯一的共享方式就是坐在他们旁边跑查询。那时，一个带真正视图的 ORM 无关工具才赢得它的位置。
如何选择
如果你还不确定，以下是我真正会给一个朋友的决策指南。
如果你是一个做快速行编辑的独立 Prisma 或 Drizzle 开发者，而且没有别人看你的数据 —— 保留内置 studio 工具。它免费，离你只有一条命令，而且它做的正是你需要的。别修没坏的东西。
如果你想要一个快速、与 ORM 无关的 SQL 客户端，而且你对写 SQL 自在 —— 想要精致、原生的体验就选 TablePlus，或者如果你需要广泛、数据库无关的支持、不介意更重的工具就选 DBeaver。两者都直接连接数据库，完全无视你的 ORM。
如果你需要把数据展示给非技术人员，或者想要 kanban/画廊/dashboard 视图又不想运行服务器 —— 那正是 BaseVolt 的用途。它是 ORM 无关的，所以无论你在 Prisma、Drizzle、Kysely 还是裸 SQL 上，它都能工作，而且它把你的数据留在你的机器上。如果那符合你的处境，那就是我会指向你的工具，即使不是我构建的，我也会说同样的话。
如果你是 Kysely 用户 —— 你本来就没有内置 studio 工具，所以一直就在这些之间做选择。数据库 GUI 是你自然的家，而同样的 ORM 无关逻辑适用：选那个视图与你工作匹配的。
而且这些并不互斥：很多开发者既运行 Prisma Studio 做快速编辑，也用一个 ORM 无关的工具来浏览、共享和做 dashboard。内置工具是你的快速路径；数据库 GUI 是给所有人的共享面。
结论
Prisma Studio 和 Drizzle Studio 是好工具，如果你对它们满意，就没有理由切换。它们免费、方便，对做开发过程中快速行编辑的独立开发者来说，它们往往是最佳答案。我是认真的。
这里的替代品与其说是 studio 工具的替代，不如说是为不同工作准备的不同形状。DBeaver 和 TablePlus 是 ORM 无关的 SQL 客户端——更快、更通用、独立于你应用的数据层，但骨子里仍然是网格，仍然是为写 SQL 的人构建的。而 BaseVolt 是那个异类：一个 ORM 无关、本地优先的管理面板，为这样的场景构建——你想要网格/画廊/kanban/dashboard 视图，而没有服务器，你的数据不离开你的机器，也不在乎每个项目用的是哪个 ORM。
重要的区分是这篇文章中间那个。一个 studio 工具通过你的 ORM 了解你的 schema，这使它毫不费力而狭窄。一个数据库 GUI 与数据库本身通信，这使它普适而略微不那么神奇。当你一个人看的时候，内置工具是正确的形状。当别人需要看数据时——尤其当那个人不是技术人员时——这个形状就错了，值得伸手去拿一个为共享而构建的工具。你可以从在线演示开始，或者在功能页面读更多关于它做什么的内容——无需注册，无需信用卡。
在 X 上找我。
