Database Modeling & Migrations

Schema design: standard normalized design, idiomatic per ORM/framework

No personal override on naming (singular vs plural tables), ID strategy (UUID vs serial/auto-increment), or timestamp columns — follow whatever the ORM/framework's own convention is (Prisma, Drizzle, Django, Rails, etc. each have their own idiom; don't fight it). Normalize by default; denormalize only when a measured read pattern justifies it (ties to warisskill-performance-optimization's measure-first rule — don't denormalize speculatively).

Migration rigor: scaled to project stage

Two modes, decided by whether the project has real production traffic depending on it: