Zero-downtime migrations are the skill that separates senior from staff Rails engineers. Anyone can write add_column :users, :role, :string. The staff engineer knows that add_index :users, :email, algorithm: :concurrently requires running outside a transaction, that renaming a column requires a multi-deploy strategy, that adding a NOT NULL constraint with a default on a table with fifty million rows will lock the table for minutes in PostgreSQL versions before 11. The strong_migrations gem catches many of these, but it is a safety net, not a substitute for understanding why certain migrations lock tables.
Replication, backup, and Point-In-Time Recovery -- you probably delegate these to your DBA or your cloud provider. Heroku runs pg_dump for you. AWS RDS handles replication. That is fine until the recovery fails and you need to understand why, or until you are at a company that runs its own PostgreSQL and you are the most senior engineer in the room. This module ensures you are not helpless in that moment.
The pg_stat_statements extension is your best friend. Install it on every PostgreSQL database you touch, including development. It records every query, how many times it ran, total execution time, and rows returned. It is how you find the query that runs ten thousand times per request because of an N+1 you did not notice. It is how you find the query that runs once but takes eight seconds because it is scanning a table with no index. Combine it with auto_explain and you have a complete diagnostic toolkit.
Monitoring database health -- active connections, lock contention, table bloat, autovacuum progress -- is as important as monitoring application health. Your app can have zero errors in your exception tracker while your database is quietly dying from bloat, approaching connection limits, or falling behind on vacuuming. By the time the app starts throwing errors, the database problem is already severe. Monitor the database directly. Always.