Database Design Doesn't Start With Table. It Starts With Consequences

Good database design starts with understanding business domain consequences, not jumping straight to CREATE TABLE. Key principles covered: treat schema changes with the same rigor as code architecture (migrations on 500M-row tables are multi-month projects), normalize to 3NF first then denormalize deliberately based on real query patterns, index foreign keys and high-cardinality WHERE/JOIN/ORDER BY columns while avoiding low-cardinality ones, and use constraints (NOT NULL, UNIQUE, CHECK, foreign keys) to encode business rules directly in the database. Performance problems are usually schema problems in disguise, not tuning problems. Practical advice includes using pg_stat_user_indexes and EXPLAIN ANALYZE to measure impact, and designing for extensibility rather than premature optimization.