как минимум, в нужности.

Буферизированный сразу выгребает все данные в буфер (на стороне питона), небуферизированный по мере потребления строк. Это имеет разные побочные эффекты. Например с небуферизированным ты должен явно получить все строки, чтобы закончить выполнение запроса и иметь возможность послать следующий запрос.

Буферизация

С буферизированным понятно.Тут курсор сразу сохраняет в память результаты запроса. Если в данном случае выбрать не все результаты, к примеру с помощью fetchone, то будет ошибка - есть непрочитанные данные. Почему в этом случае так сделано, разве нельзя было сразу удалять неиспользуемые данные?

Теперь с небуферизированным. Как здесь выгребаются результаты? Их СУБД сохраняет предварительно? Если кратко, то каком механизм взаимодействия в этом случае?

Если в данном случае выбрать не все результаты, к примеру с помощью fetchone, то будет ошибка - есть непрочитанные данные

Не в этом, а в небуферизированном.

Как здесь выгребаются результаты?

Как обычно, получаешь результаты пока не кончатся.

Их СУБД сохраняет предварительно?

Да. Но пока ты их не получил, соединение остаётся в режиме выполнения запроса, т.о. другие запросы ты уже через это же соединение давать не можешь.

каком механизм взаимодействия в этом случае

Механизм взаимодействия с чем? С точки зрения БД разницы никакой нет. Просто буферизированный курсор сам получает все данные неявно. А небуферизированным ты должен явно это сделать. Как вариант ты можешь закрыть курсор, что должно сбросить result set на стороне БД.

Вообще, небуферизированный курсор это очень специфическая вещь, которая тебе вряд ли когда-то понадобится. Разве что ты захочешь сделать какую-то свою хитрую буферизацию. Использовать же небуферизированный курсор просто так, сам по себе — это очень плохая идея.

расход озу и нагрузка на СУБД

Получается, если используется небуферизированный курсор, то и памяти(озу) расходуется меньше (т.к данные получает кусками). А как в таком случае нагрузка на СУБД(ведь данные еще выгружены не все)?

Получается буферизированный курсор меньше нагружает базу т.к все выгружается сразу, зато больше расход нашей ОЗУ.

если используется небуферизированный курсор, то и памяти(озу) расходуется меньше

На стороне питона конечно меньше. Но это пока у тебя хеловорд и одно соединение.

А как в таком случае нагрузка на СУБД(ведь данные еще выгружены не все)?

А вот тут всё плохо. В СУБД не только память может расходоваться, но ещё треды, дескрипторы и т.п. Поэтому только ради памяти так делать не надо (но конечно, ради костылей всё возможно). СУБД хуже масштабируется, чем клиенты. Тут вон в соседней теме обсуждают 16000 соединений…

Получается буферизированный курсор меньше нагружает базу

Да.

зато больше расход нашей ОЗУ

А что ОЗУ БД не наша? Ситуации конечно бывают разные, но как правило ты платишь за то и за то. Не факт что дополнительная нагрузка на БД обойдётся дешевле. Дело ведь ещё в том, что т.к. ты занимаешь соединение долго, то количество соединений тебе понадобится больше (речь не про хеловорды). Даже на клиенте это приведёт к соответствующим расходам.

Стоит отметить, что БД будет подгружать записи с диска по мере чтения, и в случае небуферизированного запроса память таки будет экономится. Но заметный эффект будет только на больших выборках, в большинстве случаев лучше использовать буферизированный запрос.

БД будет подгружать записи с диска по мере чтения, и в случае небуферизированного запроса память таки будет экономится

Может будет, может не будет. Я б не стал на это полагаться. Тем более, что большая выборка — это само по себе плохо, т.к. выбивает из буферов и кэшей (не только БД, но и ФС) другие, более актуальные данные. Если предполагается большая выборка, то лучше обрабатывать её пачками разумных размеров (т.е. отдельными запросами с лимитом).