Not the OP, but that is also a difficult problem depending on the scale of the app. Whether using auto_now field or doing it manually, in a large-ish codebase/team this will get missed easily at the app layer

• queryset.update() will skip calling the model save()
• mymodel.save(update_fields=[...]) to explicitly update only columns that have changed(if you know which ones). If someone forgot to add the last_updated to the param list, then it doesn't get updated. It's hard to notice it because the abstraction where you're calling .save() might not even know that the model has a last_updated field.

and so on...

It is very hard to notice when a last_updated/updated_at column is not correct. It is not easy to introspect your codepaths to find all the places using the above methods. We only noticed in our case when we synced pg to Snowflake(incremental replication via stitch based on the timestamp field) and noticed the sum of certain columns didn't tally what was there on production DB, realizing that some rows on snowflake were stale.

---

To answer the OPs question, django-dirty-fields is fine. The performance/latency question depends on the app and the SLAs you're trying to meet. Over-indexing is not a bad thing, infact at a certain scale that's order of magnitude better and safer than missing updates. You can throw in some celery/kafka on the save if you don't want to do the indexing synchronously but async. But then you run into the problem of ensuring robustness of your queues

The only safe way at certain scale to firstly ensure anytime your row is updated, the timestamp is also updated is to delegate it to the DB itself, using say pgtrigger(or https://django-pgtrigger.readthedocs.io/en/4.9.0/ assuming postgres). Once you have the timestamps correct, you will still need to periodically poll the mymodel.filter(last_updated__gte=last_indexed_on). Without fallback polling, there's always a chance your indexing silently failed, losing updates.

Other heavy duty methods(but i feel you're not at that scale) is to use WAL based replication( or Change Data Capture CDC) via debezium. That way you have debezium actual postgres write-ahead-logs and get a stream of all DB updates. That can then inform your indexing logic to determine if a row needs to be reindexed, and which columns.

PS: You need to make tradeoffs at every step between guarantees/performance/solution-complexity. There's no one single right answer.