Search for a command to run...
Learn Prisma ORM the practical way. Understand migrate dev, generate, migrate deploy, Prisma Studio, and production workflows with real examples.
No comments yet. Be the first to comment.
Meta Description: Learn how to convert your Next.js website into an Android app using Capacitor on Windows. Step-by-step guide with Android Studio setup, APK generation, and deployment. If you've alre
This is Part 2 of my Next.js Caching series. In Part 1, we covered Browser Cache, CDN, Router Cache, Full Route Cache, Data Cache, unstable_cache, and use cache. Previously... We learned that a requ
When someone opens your website, does Next.js immediately query your database? Not always. A request may pass through multiple cache layers before your database is even touched. The more requests serv
Introduction If you've been building with React or Next.js, you've probably heard terms like: SSR SSG ISR CSR PPR React Server Components unstable_cache At first, they all sound like differen
While building My Project, one of the biggest challenges wasn't building the UI—it was deciding how to cache data correctly. I wanted my application to: ⚡ Feel instant while navigating 🔍 Remain SEO
Akash Blog
19 posts
The first time I used Prisma, I thought it was just another ORM.
A few weeks later, I realized Prisma is actually three things:
A database migration tool
A type-safe query builder
A schema management system
The confusion usually starts when developers see commands like:
prisma migrate dev
prisma generate
prisma migrate deploy
They sound similar, but they do very different things.
This guide is the Prisma cheat sheet I wish I had when starting out.
Prisma ORM helps you interact with your database using a type-safe API instead of writing raw SQL everywhere. It also manages schema changes through migrations and generates TypeScript types directly from your schema. (Prisma)
Think of it like:
Database Schema → Prisma → Type-Safe API → Your Application
Instead of:
SELECT * FROM users;
You write:
const users = await prisma.user.findMany();
Every schema change becomes a migration file that can be committed to Git.
prisma/
└── migrations/
This means your database history lives alongside your code. (Prisma)
When you update your schema:
model User {
id Int @id
email String
}
Prisma automatically updates your TypeScript types.
No more:
user.emial
bugs.
Changing database columns, relationships, or tables becomes much safer because Prisma updates the generated client accordingly.
npm install prisma --save-dev
npm install @prisma/client
Or globally:
npm install -g prisma
npx prisma init --output ../generated/prisma
This creates:
prisma/
├── schema.prisma
└── migrations/
Configure your database URL and pull your schema:
prisma db pull
Prisma will inspect your database and generate models automatically. (Prisma)
Inside:
Schema.prisma
model Restaurant {
id Int @id @default(autoincrement())
name String
}
Run:
npx prisma migrate dev --name init
Prisma will:
✅ Compare schemas
✅ Generate migration SQL files
✅ Apply migrations to your development database configured in .env
✅ Update migration history
✅ Create database tables
Prisma stores migration history in the _prisma_migrations table. (Prisma)
Launch Prisma's built-in database GUI:
npx prisma studio
Opens:
http://localhost:5555
Think of it as a lightweight admin panel for your database.
You can:
View records
Edit data
Delete records
Inspect relationships
without writing SQL.
Probably the most important command:
npx prisma migrate dev --name add_users
What actually happens?
Checks migration history
Detects schema changes
Creates a migration file
Applies migration to your development database
Updates _prisma_migrations history table
Prisma explicitly recommends using this command only during development. (Prisma)
⚠️ Never run this on production.
npx prisma generate
This regenerates the Prisma Client based on your schema.
Why does this matter?
Because your code uses generated APIs like:
prisma.user.findMany()
Whenever your schema changes, regenerate the client.
npx prisma generate
Prisma Client is generated from your schema and provides the type-safe API your application uses. (Prisma)
This is the production command.
npx prisma migrate deploy
Unlike migrate dev, it does not:
❌ Generate migrations
❌ Detect schema drift
❌ Create migration files
It simply:
✅ Looks for migration files already committed to Git
✅ Applies any pending migrations
That's exactly why it's safe for production environments. (Prisma)
A typical workflow:
Development
↓
prisma migrate dev
↓
Git Commit
↓
Production
↓
prisma migrate deploy
Check whether your database and migration files are in sync:
npx prisma migrate status
Useful before deployments.
Need a clean slate?
npx prisma migrate reset
This command:
Drops the database
Recreates it
Reapplies all migrations
⚠️ All data is lost.
Use only in development environments. (Prisma)
Every time you run:
npx prisma migrate dev --name something
a new migration gets created.
During MVP development, it's common to accumulate dozens of migrations & that's totally normal because that is how you see your schema history.
Example:
migrations/
├── add_user
├── add_role
├── add_status
├── fix_role
├── fix_role_again
Many teams periodically clean this up.
Reset:
npx prisma migrate reset
Delete:
prisma/migrations/
Create a fresh migration:
npx prisma migrate dev --name init
Result:
migrations/
└── init
Much cleaner.
# Modify schema.prisma
npx prisma migrate dev --name add_feature
npx prisma generate
npx prisma studio
# CI/CD
npx prisma migrate deploy
Never:
npx prisma migrate dev
on production servers. Prisma's documentation recommends using migrate deploy for production and CI/CD workflows. (Prisma)
Could you build your app using only PostgreSQL and raw SQL files?
Absolutely.
But once your project starts growing, Prisma gives you:
Type safety
Migration history
Better developer experience
Cleaner code
Easier schema management
For small prototypes, raw SQL is fine.
For real-world TypeScript applications, Prisma quickly pays for itself.