Introduction

In the talk "10 Costly Database Performance Mistakes (and How to Fix Them)", Andrew Atkinson shares insights from working with Rails and Postgres applications, drawing on real-world experience to identify common pitfalls that can cause significant performance issues and financial costs in production environments. Delivered at RailsConf 2025, this session guides developers through 10 major mistakes, explaining why they arise, their impacts, and actionable strategies to resolve them.

Key Points and Mistakes Discussed

• Infrequent Releases:

  • Slow release cycles decrease team agility and extend incident resolution times. Solutions include adopting trunk-based development, using feature flags, tracking key DevOps metrics (DORA/SPACE), and considering tools like the anchor migrations gem for safer, more efficient schema changes.

• Database Inexperience:

  • Many Rails teams lack deep database expertise, leading to inefficient queries and poor schema choices. Recommendations include hiring or developing DBA talent, leveraging production clones for safe experimentation, and using educational resources and communities.

• Speculative Database Design:

  • Avoiding constraints or normalization due to speculative future needs can result in data bugs and maintenance headaches. Adopt constraint-driven design (the "CORE" principles), align database constraints with application validations, and normalize by default.

• Missing Database Monitoring:

  • A lack of focused database monitoring makes it harder to triage and resolve performance incidents. Solutions include logging detailed query metadata, tracking query execution plans, and using tools/extensions like query logs, marginelia, PGHero, PG Analyze, and PG Badger.

• ORM Pitfalls:

  • Overuse or misuse of ORM features can generate unnecessary or inefficient queries (e.g., excessive COUNTs, huge IN lists, SELECT *). Auditing queries, limiting columns, restructuring queries, using cache features, and adopting more scalable approaches to pagination are recommended.

• DDL Fear:

  • Hesitance to make schema changes, especially at scale, leads to code workarounds and technical debt. Practice DDLs on production clones, use linting tools for safe migrations, take advantage of ignored columns, and set appropriate lock timeouts.

• Excessive Data Access:

  • Retrieving or aggregating excessive data degrades performance. Analyze and reduce data access patterns, implement advanced indexing, and consider data partitioning or precalculating aggregates (using gems like rollup and scenic).

• Missing Data Archival:

  • Failure to archive old, seldom-accessed data increases latency and server costs. Archive unneeded data, migrate large tables to partitions, and prefer detaching partitions over massive deletes.

• Missing Database Maintenance:

  • Running outdated software, neglecting bloat cleanup, and not tuning auto-maintenance features can harm performance and security. Regularly upgrade databases, tune maintenance parameters, prune obsolete objects, and rebuild or reindex as needed.

• Rejecting Mechanical Sympathy:

  • Not understanding the database’s internal workings leads to suboptimal design and resource misuse. Developers should inspect SQL generated by ORMs, use database-specific optimizations, prevent lazy loading, and set prudent operational boundaries.

Illustrative Examples

• Use of real-world Rails migrations and SQL linting tools (Squawk, anchor migrations)
• Case references to poorly designed index strategies, inefficient aggregates, and massive delete scenarios handled by partitioning

Conclusion and Takeaways

The talk emphasizes proactive monitoring, regular maintenance, a willingness to evolve schemas, and developing a deeper understanding of how relational databases operate. By addressing these 10 pitfalls with practical solutions, Rails teams can significantly boost performance, reduce costs, and foster more maintainable applications.