performance

I stopped doing row-by-row imports once they started hammering the DB. In Migration (unique index), I added a real uniqueness guarantee on provider + uid, because bulk writes only stay correct if the database can enforce constraints. Then, in Bulk ups

When you need to invalidate caches by changing timestamps, use touch_all to avoid per-record callbacks. It’s fast, explicit, and doesn’t run unintended side effects.

OFFSET gets slower as tables grow and becomes inconsistent under writes. Keyset pagination is stable and fast: paginate by (created_at, id) cursor. This is a common “senior Rails” upgrade for activity feeds.

Most ‘caching’ bugs are really invalidation bugs, so I stick to a simple cache-aside pattern with conservative TTLs and treat cache misses as normal. The big failure mode to avoid is a stampede: if many requests miss at once, you can crush your DB. Fo

Backfills often fail because we accidentally load full records and associations. Use select to fetch only needed columns and find_each to keep memory flat. This is basic, but it’s where outages come from.

Heavy work inside a transaction increases lock time and deadlock risk. Use after_save_commit to schedule slow tasks (thumb generation, external sync) once the write is durable.

ETags are a simple high-impact performance lever: they reduce bandwidth and controller CPU. Use stale? with a stable ETag component list and last_modified so intermediary caches and browsers can do conditional GET.

Bulk operations reduce database round-trips dramatically. I use bulk_create() for inserting many objects at once, bulk_update() for updates, and update() for queryset-level updates. These bypass save() methods and signals for speed. For large datasets

A per-request statement_timeout is a great “seatbelt” for endpoints that can run bad queries when parameters are unexpected. You can set it for a block; Postgres enforces the wall clock limit.

The only() method loads specified fields only, while defer() excludes specified fields. This reduces data transfer and memory usage. I use only() when I need just a few fields from large models. For read-only displays, this prevents loading unnecessar

Connection pooling reuses database connections instead of creating new ones per request. I use django-db-pool or configure persistent connections with CONN_MAX_AGE. This reduces connection overhead significantly. For high-traffic sites, I set appropri

Django Debug Toolbar reveals query counts, cache hits, and template rendering time. I add it only in development settings. The toolbar shows all SQL queries which helps identify N+1 problems. I use the profiler panel to find slow code. The cache panel