Your database skills are not 'good to have' (2023)

ORMs vs Raw SQL

• Many argue “smart developers” should know SQL well and still use ORMs: ORMs speed up CRUD work, keep code typed, centralize schema, handle migrations, and provide escape hatches to raw SQL.
• Common pattern: use ORM for most operations, drop to hand-written SQL for the small fraction of hot, complex queries.
• Supporters emphasize Pareto thinking: <5–20% of queries need heavy optimization; ORMs make the remaining 80–95% cheaper to write and maintain.
• Critics say ORMs are leaky abstractions with hidden costs, encourage poor modeling, and can normalize performance problems (e.g., N+1 queries, retrieving too many columns). Some report eventually realizing they simply don’t need an ORM.
• There’s disagreement on terminology: some insist “ORM” is strictly the mapping layer, distinct from query builders / Active Record patterns; others bundle these together in practice.

Database Performance & Indexing

• Thread strongly emphasizes learning how databases and indexes actually work: B/B+ trees, clustered vs heap storage, visibility maps, statistics, partial indexes, and the impact of NULLs.
• Recommended approach: design indexes around real query patterns and benchmark; tools like query planners and EXPLAIN are crucial.
• Reference to a well-known index-tuning resource and book as particularly helpful in understanding performance.

Joins, Normalization, and Materialization

• Several push back against “never join more than 3 tables,” calling it outdated for modern engines if indexes are good.
• Joins are usually not the bottleneck; lack of indexes or bad query patterns is.
• For analytics and dashboards, some advocate pre-aggregated tables / materialized views derived from core tables for dramatic speedups.

Relational vs NoSQL / Extra Systems

• Strong theme: fix your relational database usage before adding DynamoDB, Kafka, Redis, etc.
• Suggestions: use read replicas instead of Redis when feasible, keep relational data clean and small, and understand that misuse of SQL likely implies misuse of other data systems too.

Operational Concerns and Query Planners

• Experiences with PostgreSQL changing query plans and causing latency spikes; mitigations include VACUUM / ANALYZE, adjusting statistics, and specialized extensions.
• Some argue these incidents show the need for real DBAs; query-plan changes are usually rooted in maintenance or data distribution, not randomness.

Learning Resources & Code Examples

• Suggestions include reading ORM and RDBMS documentation and studying mature open-source web backends that evolved under real performance constraints.