1. Implicit conversion in WHERE breaks indexes — full table scan instead of index seek

2. On 5M rows: implicit conversion = 8,000ms vs explicit match = 80ms (100× slower)

3. DECIMAL arithmetic is ~2–3× slower than FLOAT — justified only for financial data

4. JSONB (PostgreSQL) is 3–5× faster than JSON for reads — binary format + GIN index

5. VARCHAR(50) uses only actual length — don't default to VARCHAR(255) for everything

6. CHAR(n) is faster for fixed-length lookups (country codes, ISO codes) due to predictable offsets

7. BIGINT costs 2× storage of INT — only upgrade when values exceed ±2.1 billion

8. TRY_CAST adds a small overhead vs CAST — worth it for user-input ETL pipelines

Implicit conversion in WHERE forces full table scan — 100× slower on 5M+ row tables

JSONB with GIN index enables fast containment queries (@>) without scanning all rows

DECIMAL arithmetic is 2–3× slower than FLOAT — use FLOAT only for scientific/approximate data

CHAR(n) outperforms VARCHAR for fixed-length values — predictable row offsets in storage

Right-sized types improve buffer cache hit rates: 100M rows × 8 bytes saved = 800MB in cache

EXPLAIN / EXPLAIN ANALYZE: always verify index is being used after type changes

Implicit conversion in WHERE breaks indexes: WHERE phone = 1234567890 (integer vs VARCHAR)

FLOAT for money causes rounding: 0.1 + 0.2 = 0.30000000000000004 — fails financial audits

TIMESTAMP without timezone: order placed at 22:00 PST → displayed as 22:00 UTC (wrong time)

CAST without TRY_CAST crashes entire query on one bad row in ETL pipelines

VARCHAR(255) default for everything wastes 5–10× storage vs right-sized columns

INT overflow: 2,147,483,647 + 1 throws error — check ID sequences before they wrap