Normalization theory will feel academic. First normal form, second normal form, Boyce-Codd -- it reads like a textbook because it is a textbook. Then you will encounter a polymorphic association in production where the commentable_type column has twelve distinct values, there is no foreign key constraint, and a JOIN across three of those types takes ten seconds. You will wish you had learned this earlier.
Rails conventions are database design patterns with tradeoffs that the framework never explains to you. Single Table Inheritance puts unrelated data in one table and fills it with NULLs. Polymorphic associations break referential integrity because foreign keys cannot point to multiple tables. has_many :through creates join tables that sometimes need their own indices and sometimes need their own columns. None of this is wrong, exactly. But Rails presents these as "the way" rather than "one option with specific costs." This module teaches you to see the costs.
The "convention over configuration" philosophy that makes Rails productive also hides design decisions you should be making consciously. The default id column is a sequential integer -- fine, until you need UUIDs for distributed systems or security. The default timestamp columns are created_at and updated_at without time zones, which is a landmine for any app that crosses time zones. The default lack of check constraints means your database trusts your application validations completely, which is naive.
After this module, you will look at a schema.rb file and see it differently. You will see missing indexes, missing constraints, denormalization that should be normalized, normalization that should be denormalized. That is the shift -- from accepting the schema Rails generates to designing the schema your data actually needs.