NOT NULL constraints on required fields

Nullable required fields shift data integrity guarantees from the database to application code. When users.email or orders.status allows NULL, any code path — a background job, a direct SQL migration, a third-party integration — can insert invalid rows that the application is not equipped to handle. The downstream effect is defensive ?. and null-coalescing operators scattered throughout the codebase, and sporadic runtime errors when those checks are missed. ISO 25010 functional-correctness treats this as a schema design failure: fields that have no valid null state should have that stated in the schema, not enforced by convention.

Add NOT NULL to required columns in a migration. In Prisma, remove the ? suffix from required fields. When retrofitting onto a column that has existing NULLs, backfill before constraining.

-- Backfill first, then constrain
UPDATE orders SET status = 'pending' WHERE status IS NULL;
ALTER TABLE orders ALTER COLUMN status SET NOT NULL;

ALTER TABLE users
  ALTER COLUMN email SET NOT NULL,
  ALTER COLUMN created_at SET NOT NULL;

model User {
  email     String   // NOT NULL — no ? suffix
  createdAt DateTime @default(now())
  bio       String?  // nullable — intentional
}

Legitimately optional fields (bio, avatar_url, middle_name) keep their ?; every other field should have a documented reason for being nullable.