This module has the highest interview ROI in the entire databases curriculum. "How would you optimize this slow query?" is the number one database question in Rails interviews. It comes up at every level -- mid, senior, staff -- and the expected depth of your answer is what separates those levels. A mid-level engineer says "add an index." A senior engineer says "add a composite index on these two columns in this order because the query filters on both and the selectivity of the first column is higher." A staff engineer says all of that and then explains why the index might not help if the table has high write throughput.
Indexing strategy is not "add an index to every column." That is the cargo cult version. Real indexing strategy means understanding B-tree structure, knowing that a composite index on (user_id, created_at) serves queries filtering on user_id alone but not created_at alone, knowing when a partial index saves space and speeds up queries, knowing when a covering index lets PostgreSQL answer the query from the index without touching the table at all. This is the difference between solving slow queries by accident and solving them by understanding.
Vlad Mihalcea's High-Performance Java Persistence course is dense and database-agnostic despite the Java title. He is a Hibernate expert, and Hibernate is to Java what ActiveRecord is to Ruby. Translate his examples mentally. When he talks about entity fetching strategies, think about .includes versus .joins versus .preload. When he talks about connection management, think about your database.yml pool setting.
Connection pooling with PgBouncer is the difference between "our app handles 100 requests per second" and "our app handles 1,000." Rails opens a database connection per thread, and PostgreSQL connections are expensive -- each one is a forked process consuming memory. PgBouncer sits between your app and the database, recycling connections. Learn it. Deploy it. It is not optional at scale.