Prisma Studio Showing Old Schema After a Migration (Even Though the DB Was Correct)

You run a migration. You verify the database. Everything looks right. Your backend API works. Your schema.prisma is updated.

…and yet Prisma Studio is stubbornly showing the old columns like it never got the memo.

If you’ve ever had that “am I losing my mind?” moment, this write-up is designed to be interactive. You’ll get prompted along the way to choose what you think is wrong before we reveal what actually was.

The Setup: What Changed?

The channels table was migrated from the old schema:

• isDirect, isGroup, ownerId, ownerType

to the new schema:

• type, brandId, autoJoin (plus new fields like created_by_id)

Everything was updated accordingly:

• migration script ran
• schema.prisma reflected the new shape
• Prisma Client in the backend was regenerated

But Prisma Studio… had other ideas.

Quick Reality Check: What Was Actually Happening?

Here’s the split-brain situation:

Component

What it showed

Database (psql)

✅ New columns exist

Prisma Studio UI

❌ Old columns still displayed

Backend API

✅ Working with the new schema

schema.prisma

✅ Updated correctly

So Prisma Studio was the only liar in the room.

🧠 Interactive Checkpoint #1

If the DB is correct and Prisma schema is correct, why would Prisma Studio still be wrong?

Pick one:

A. Prisma Studio reads from a cached schema file somewhere
B. Prisma Studio reads directly from the database, so the DB must actually be wrong
C. Prisma Studio generates its own Prisma Client and might not be regenerating correctly
D. Docker could be reusing persistent data or volumes

✅ Correct answers: A, C, and D
(And B is the classic trap. Because psql already confirmed the DB schema was correct.)

Symptoms (What You Observed)

Database Schema (verified via SQL)

Correct columns like:

• type
• brand_id
• auto_join
• created_by_id

Prisma Studio UI

Still showed old columns like:

• is_direct
• is_group
• owner_id
• owner_type

Backend API

Successfully operated on new schema.

🧠 Interactive Checkpoint #2

What would you try first?

Pick one:

A. Rebuild Docker containers
B. Restart Prisma Studio
C. Regenerate Prisma Client
D. Verify with direct SQL
E. All of the above

✅ The realistic answer: E All of the above
…and that’s exactly what happened next.

Troubleshooting Attempts (That Didn’t Work)

These were all tried and all failed to fix Prisma Studio:

1. Verified schema through psql
2. Confirmed the updated schema.prisma
3. Regenerated Prisma Client in backend container
4. Rebuilt backend Docker container without cache
5. Restarted Prisma Studio multiple times
6. Deleted and recreated the Prisma Studio container

And still: Prisma Studio was showing the old schema.

🧠 Interactive Checkpoint #3

At this point, what conclusion would you lean toward?

Pick one:

A. Prisma Studio UI bug
B. Prisma Studio is stuck using an old Prisma Client build
C. The database isn’t really updated (psql must be wrong)
D. Something persistent is surviving container rebuilds

✅ Correct: B and D
This wasn’t random. Something persisted.

Root Cause: Docker Volume Persistence + Prisma Studio Caching

This was caused by Docker volume persistence, plus how Prisma Studio generates and caches Prisma Client files.

Here’s what happened:

• Prisma Studio container mounted the Prisma directory as a volume:

./backend/prisma:/app/prisma

• Prisma Studio generates its own Prisma Client
• Prisma Client artifacts are generated into:

node_modules/.prisma/

• Docker volume persistence meant old cached schema artifacts could survive rebuilds
• Result: Prisma Studio UI kept reading stale metadata even though everything else was correct

The backend worked because it regenerated the Prisma Client properly in its own environment.

Prisma Studio was stuck using its own cached view of reality.

The Fix (Development Only): Remove and Recreate the Docker Volume

The winning move was wiping the persisted database volume:

# Stop all containers docker-compose down # Remove the database volume (WARNING: This deletes all data) docker volume rm trybe-platform_supabase_db_data 
# Start containers again - fresh database will be created docker-compose up -d

After that, Prisma Studio immediately displayed the correct schema.

Why This Worked (In Plain Terms)

Removing the volume did four important things:

1. Fresh Database
   • no old tables/columns persisted
2. Schema Sync
   • Prisma could rebuild from schema.prisma with no surprises
3. No Migration History Conflict
   • no legacy shape lingering in the DB state
4. Clean Slate for Prisma Studio
   • forced Prisma Studio to regenerate everything properly

🧠 Interactive Checkpoint #4

If removing the DB volume fixed it, what does that imply?

Pick one:

A. Prisma Studio was reading an outdated database state
B. Prisma Studio was reading outdated Prisma Client artifacts
C. Docker was persisting more than you thought
D. All of the above

✅ Correct: D - All of the above

Key Learnings

1) Docker volumes outlive container rebuilds

Rebuilding containers doesn’t mean rebuilding state.

2) Prisma Studio generates its own Prisma Client

So it can fall out of sync even if your backend is perfect.

3) Volume mounts can create mismatched realities

If Prisma Studio sees a different node_modules/.prisma/ state than you expect, weird things happen.

4) In development, wiping volumes can be the fastest “truth reset”

Especially after major schema changes.

Best Practices for Future You

When doing major schema changes in dev

Use:

docker-compose down -v docker-compose up -d

Be explicit about Prisma generation

Generate inside the container that is running Studio if needed:

docker-compose exec prisma-studio npx prisma generate

Always trust psql over UI

Use direct SQL checks like:

SELECT column_name, data_type, udt_name FROM information_schema.columns WHERE table_schema = 'public' AND table_name = 'channels' ORDER BY ordinal_position;

Closing Thought (One Last Prompt)

If you ever hit this again, ask yourself:

Prisma Studio is showing old columns… what’s more likely?

A. The migration didn’t run
B. Prisma Studio is stuck in a cached world
C. Prisma schema didn’t update
D. PostgreSQL is lying

✅ Most of the time: B

Because Prisma Studio doesn’t just “display the database.”
It displays what it thinks the schema is and that belief can get stuck.

If this helped and you’d like more posts like this (interactive debugging, root-cause breakdowns, and fixes that actually work), drop a quick comment or share what you want me to cover next.

If this post clicked with you, you'll love the newsletter. It's where I share raw, no-fluff lessons from real projects. The kind of stuff you don't find in documentation.

If you feel like it, my community is always open for like minded engineers who seek to level up their game. You are more than welcome to hang out with us. We talk code, chaos, and the craft of building things that don't break. Join the Discord channel

Lastly, everything I make is powered by you.

If you'd like to keep this campfire burning, you can drop a tip in the Tip Jar … or simply spread the word. Every bit helps.