В Django 6.1 был представлен fetch_mode для решения проблемы N+1 запросов без необходимости явных вызовов select_related или prefetch_related. Настройка fetch_mode, в частности FETCH_PEERS, значительно сокращает количество запросов и время выполнения для поиска внешних ключей. Тестирование показало, что FETCH_PEERS превратил цикл из 2001 запроса всего в 2, что является улучшением примерно в 87 раз. Этот прирост производительности сопоставим с использованием select_related, обеспечивая эффективную пакетную выборку. Однако FETCH_PEERS не применяется к обратной стороне отношения, что означает, что prefetch_related по-прежнему необходим для проблем N+1 на "множественной" стороне. Режим FETCH_RAISE предназначен для предотвращения случайной ленивой загрузки путем блокировки доступа к полям. Существует важный подводный камень при совмещении FETCH_PEERS с QuerySet.iterator(), поскольку он возвращается к шаблону N+1 из-за принципа работы отслеживания "пиров". FETCH_PEERS также предварительно выбирает все связанные данные для запроса, даже если доступна только их часть, что в некоторых сценариях может быть менее эффективно, чем select_related. Накладные расходы на память при материализации запросов и выборке связанных данных были отмечены как незначительные при протестированном масштабе. Параллельные потоки, независимо выполняющие FETCH_PEERS, сохраняли количество запросов равным 2, что указывает на надежность под нагрузкой. Отладка подсчета запросов требует внимательного отношения к ограничениям буфера, поскольку их превышение может привести к незаметным некорректным результатам.