Design a normalized table schema for a new feature without breaking the tables already in production

You are a database architect designing the schema for a new feature that has to coexist with tables already live in production — this is not a greenfield design exercise, so every decision has to account for what already exists and what would break if handled carelessly.

FEATURE BEING ADDED
Let a customer save multiple shipping addresses and pick a default one at checkout.

EXISTING RELEVANT TABLES
customers(id, name, email), orders(id, customer_id, shipping_address_text) — address is currently a single free-text column on orders.

DATABASE ENGINE AND VERSION
PostgreSQL 15, running on RDS

EXPECTED SCALE AND ACCESS PATTERN
orders table has ~40M rows and is read on every checkout page load; write volume is ~50k orders/day.

CONSTRAINTS THAT CANNOT CHANGE
No downtime allowed during business hours (9am-9pm ET); a nightly BI job queries orders.shipping_address_text directly and can't break.

PHASE 1 — SCHEMA DESIGN
Design the new tables and any columns added to existing tables, normalized to at least 3NF unless the stated access pattern gives a specific, named reason to denormalize (a read path that would otherwise require a join across more than three tables on every request, for example) — and if you do denormalize anything, say exactly which normal-form rule you're breaking and why the access pattern justifies it, rather than denormalizing by default and calling it a performance decision after the fact. Every foreign key needs an explicit ON DELETE behavior (CASCADE, RESTRICT, SET NULL) chosen deliberately, not left at the engine default, because the default silently varies by engine and picking it by omission is how orphaned rows or unintended cascading deletes happen later.

PHASE 2 — MIGRATION PLAN
Given the existing tables listed above already have production data and traffic, write the migration as an ordered list of individually-reversible steps, each one safe to run without locking the affected table for longer than a few seconds — call out specifically any step that would require a full table rewrite or an ACCESS EXCLUSIVE lock at the stated scale, and propose the safer alternative (adding a nullable column first and backfilling in batches, for example, rather than adding a NOT NULL column with a default directly). Do not propose a single big migration script that does everything in one transaction if any individual step in it is risky at the stated scale.

PHASE 3 — WHAT COULD GO WRONG
Name the one existing table most likely to have data that violates a new constraint you're adding (a NOT NULL, a new foreign key, a new UNIQUE constraint) and specify how you'd find out before the migration runs, not after it fails partway through.

OUTPUT FORMAT
1. Schema as DDL (CREATE TABLE / ALTER TABLE statements).
2. One-paragraph explanation of any deliberate denormalization.
3. The ordered, reversible migration step list.
4. The pre-migration data-validation query for the risk named in Phase 3.