QuerySet.iterator memory limits across database backends

Memory Management for Large Result Sets

Django's QuerySet.iterator() is designed to reduce memory consumption by bypassing the internal QuerySet cache, allowing large datasets to be processed without loading every record into memory at once.

Backend-Specific Cursor Behavior

The effectiveness of this feature appears to depend on the underlying database backend's support for server-side cursors. While some backends implement true streaming with small batched fetches, others may still materialize the entire result set before the iterator yields objects, potentially negating the intended memory savings.

Constraint Considerations

Using iterator() disables result caching, so any subsequent access to the same QuerySet instance triggers a new database round-trip. Additionally, combining iterator() with prefetch_related() may introduce unexpected memory overhead, since related objects are still fetched eagerly.

Does QuerySet.iterator() consistently provide memory relief across all supported Django database backends, or does it rely entirely on each backend's native server-side cursor implementation? How should the memory trade-off be evaluated when combining iterator() with prefetch_related()?