FTFA > Don't use unique_together, use UniqueConstraint instead > Always explicitly set db_index and add a comment > Always check the SQL generated by

FTFA > Don't use unique_together, use UniqueConstraint instead > Always explicitly set db_index and add a comment > Always check the SQL generated by migrations before applying them > Provide reverse migration operations whenever possible > Use concurrent index operations in busy systems > Indexes on foreign keys are used indirectly by deletes > Use partial indexes when possible > Adjust the order of migration operations to reduce impact on live systems > Explicitly state tables to lock when using select_for_update > Use no_key=True when selecting a row for update to allow referencing objects to be created This seems like you need much more non-essential knowledge than simply knowing SQL. Just not using an ORM bypasses so many footguns! TBH, looking at the code to do this, it seems simpler to just bypass the ORM and use a thin wrapper to the DB. Since the language in use here supports reflection, every query can automagically return a proper object with typed fields, at which point you gotta ask yourself "what value am I getting out of the ORM in exchange for all these footguns?"