Why mature teams think about lock impact before running a migration, not after it blocks production.
Your win: explain why schema changes are operational events, describe lock risk in plain language, and justify patterns like CREATE INDEX CONCURRENTLY.
In plain English
Plain English: a migration is not just “change the schema.” It is a live operation against a busy system, and some schema changes can block traffic in ways your app team feels immediately.
The problem: a correct migration can still be dangerous
Senior engineers do not judge a migration only by whether the SQL is correct. They also ask what it locks, how long it might run, whether it can be staged, and whether it is safe during normal traffic.
The mental model
DDL changes participate in concurrency too. Schema-change safety is really lock-risk management plus rollout design.
The pattern: what mature teams watch for
lock level and lock duration
whether the change blocks reads, writes, or both
whether a large backfill must be split into safer stages
whether long-lived transactions can keep old snapshots or locks alive
Anchor — the migration habit in this repo
This repo already uses concurrent index creation in migrations. That is exactly the kind of operational detail senior interviewers want you to notice and explain.
Common mistake
Treating migrations as pure developer chores and noticing lock behaviour only after deployment starts to stall or fail.
Read this next
Explicit locking + CREATE INDEX
The lock semantics and concurrent-index trade-offs are best learned from the official docs. Read them with deployment safety in mind, not just DDL syntax in mind.