How to sync your local DB when prod was changed manually
You SSHed into your server and ran an ALTER TABLE directly in psql. Now your production schema is ahead of your local machine. Here’s the…

How to sync your local DB when prod was changed manually
You SSHed into your server and ran an ALTER TABLE directly in psql. Now your production schema is ahead of your local machine. Here’s the clean way to pull it back.
The problem
When you make a manual change in production — adding a column, renaming a field, creating a new table — Prisma has no idea it happened. Your local schema.prisma is now out of sync with the real database, and your migration history doesn't reflect it either.
Running prisma migrate dev after this could wipe your manual changes or throw errors. Don't do it yet.
Step 1 — open an SSH tunnel to your VPS
PostgreSQL on your VPS doesn’t expose port 5432 to the internet (and it shouldn’t). You need a secure tunnel to reach it from your local machine.
Open a dedicated terminal and run this, then leave it open:
Terminal 1 — keep open
ssh -L 5433:localhost:5432 root@YOUR_VPS_IP -N
This forwards your local port 5433 to the server's 5432. While this terminal is running, your VPS database is reachable at localhost:5433.
Step 2 — pull the schema with Prisma
In a second terminal, navigate to your project folder and run:
Terminal 2 — your project
npx prisma db pull \
--url="postgresql://myuser:password@localhost:5433/mydb"
Prisma will introspect the live database and rewrite your prisma/schema.prisma to match it exactly — including any fields you added manually.
Step 2.5 — fix the datasource url after pulling
This is a step many people miss. After db pull, Prisma may have overwritten your datasource block with the hardcoded tunnel URL:
What prisma db pull writes (wrong)
datasource db {
provider = "postgresql"
url = "postgresql://myuser:password@localhost:5433/mydb"
}
Never commit a hardcoded database URL to git. It exposes your credentials and will break on other environments.
Always restore it back to use the environment variable:
prisma/schema.prisma — restore this
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
Make this a habit
Every time you run db pull, check and fix the datasource url before committing. Your .env file should hold the real local URL, and your VPS .env holds the prod URL — schema.prisma stays the same everywhere.
Step 3 — apply the schema to your local DB
Now push the updated schema to your local PostgreSQL so your dev environment matches prod:
npx prisma db push
This uses the DATABASE_URL from your local .env — not the tunnel URL.
Step 4 — regenerate the Prisma client
npx prisma generate
Step 5 — commit and push to git
git add prisma/schema.prisma
git commit -m "sync schema from prod manual changes"
git push
You can now close the SSH tunnel terminal. Local and prod are back in sync.
Full flow at a glance
1 Open SSH tunnel — ssh -L 5433:localhost:5432 root@VPS_IP -N
2 Pull schema — npx prisma db pull --url="...localhost:5433/mydb"
3 Restore env var — set url = env("DATABASE_URL") in schema.prisma
4 Apply locally — npx prisma db push
5 Regenerate client — npx prisma generate
6 Commit to git — git add prisma/schema.prisma && git commit -m "sync"
Going forward
Today (db push)
Fast, no history. Good for solo devs and early stage. Manual prod changes need a db pull to re-sync.
Future (migrate)
Every change gets a timestamped file. Deploy with prisma migrate deploy. Full audit trail.
The migration approach means you never need to db pull from prod again — all changes originate from your local machine and travel through git to the server.
메타데이터
- post_id
- 76457e674d64
- slug
- how-to-sync-your-local-db-when-prod-was-changed-manually-76457e674d64
- url
- https://medium.com/@shoomankhatri/how-to-sync-your-local-db-when-prod-was-changed-manually-76457e674d64
- canonical_url
- https://medium.com/@shoomankhatri/how-to-sync-your-local-db-when-prod-was-changed-manually-76457e674d64
- author_url
- https://medium.com/@shoomankhatri
- status
- ok
- fetched_at
- 2026-07-11 20:55:18