Prisma Studio is not an admin panel

divinesta — Tue, 18 Aug 2026 21:18:34 +0000

If you build with Prisma, you already know Prisma Studio. Run one command and you get a clean, visual way to browse and edit rows in your database. It's genuinely useful, and I reach for it every day while developing.

But somewhere between "I need to look at my data" and "I need to let a support agent safely edit a customer's record in production," Prisma Studio quietly stops being the right tool. It was never trying to be that tool. It's a database viewer. An admin panel is something else, and the gap between the two is exactly the part that matters once real people and real permissions are involved.

I ended up building a small package to fill that gap for my own Express + Prisma apps. Writing it forced me to be precise about what an admin panel actually adds on top of a database browser. Here's the distinction as I now understand it.

A database browser shows rows. An admin panel governs them.

Prisma Studio connects to your database and shows you everything. That's the point of it, and it's also why you'd never hand it to a non-engineer or expose it in production. It has no concept of who is looking, what they're allowed to do, or which rows they're allowed to touch.

An admin panel's whole job is those three questions. The package I built mounts a React UI at /admin and a guarded JSON API under /admin/api/* on your existing Express app. Every single request through that API runs the same pipeline, in the same order:

authentication → permission check → tenant scope → validation → Prisma mutation/query → optional audit event

That ordering is the entire difference. A database browser skips straight to the mutation. An admin panel refuses to run the mutation until it knows the request is authenticated, permitted, scoped to the right tenant, and valid.

Permissions and scope are two different questions

This was the design decision I care most about, because collapsing these two into one is how data leaks happen.

Permissions decide which actions a role may take. Can an editor delete a post? Can a support agent create a user?
Scope decides which rows a role may see or act on. A support agent for Tenant A should never be able to read, update, or delete Tenant B's records — even for actions they're otherwise fully permitted to perform.

Keeping these separate means "you may edit users" and "you may edit these users" are enforced independently. Scope is applied everywhere it needs to be: lists, single reads, updates, deletes, the choices offered in relation dropdowns, and custom actions. It's the kind of thing that's easy to get 90% right and have the last 10% be a cross-tenant data breach, so the test suite specifically checks that Tenant A cannot view, update, or delete Tenant B's records.

Prisma Studio has no place to even express this idea. There's no role, so there's nothing to scope.

Auth that doesn't touch your users table

Built-in authentication is optional, and when you use it, it deliberately stays out of your application's own data. It uses separate ExpressAdminUser and ExpressAdminSession models rather than reading or modifying your app's user and session records. Your admins and your end users are different populations, and mixing them is a recipe for accidents.

The built-in auth ships with an admin login page, database-backed sessions, a createsuperuser CLI command, HttpOnly / SameSite=Lax cookies, and sign-in throttling. If you already have an auth system you'd rather use, you can bring that instead.

Audit logging you own

After a successful mutation, the library can emit safe event metadata so you have a record of who changed what. Deliberately, it does not ship its own audit table. You own where those events go and how long they live, because audit storage is a policy decision that belongs to your application, not to a library.

What it is not — and this part is important

I want to be honest about the boundaries, because the fastest way to disappoint someone is to let them think this is something it isn't.

It is not a CMS and not a general-purpose internal-tools platform. Today, writes support scalar fields plus selecting a single belongsTo foreign key. That means:

No nested writes
No many-to-many editors
No hasMany inline tables
No file uploads
No rich text or custom widgets
No exports
No built-in audit-history UI

It currently supports Prisma 7.5.x only.

If you need those things, you need a heavier tool, and that's a completely reasonable place to land. What this package does is take the narrow, common, security-sensitive case - schema-driven CRUD that respects permissions and tenant boundaries - and do that part carefully.

The one-line version

Prisma Studio answers "what's in my database?" An admin panel answers "who is allowed to change what, and did we record it?" Both are worth having. They're just not the same tool, and reaching for the database browser when you needed the governance layer is a mistake you usually only notice after it's cost you something.``