Сергей Горностаев

Это происходит эволюционно. Как говорится, make it run, make it right, make it fast. Сначала учишься хоть как-то работать с базами. Потом учишься их правильно проектировать с позиции удобства использования и доработки. Потом учишься их проектировать с учётом производительности. На первом этапе помогает учебник по SQL для начинающих. На втором этапе учебники по теории реляционных баз данных. На третьем документация конкретной СУРБД и боевой опыт. Одного учебника мало, нужны годы хождения по граблям.

Конкретно про анализ плана выполнения есть хорошие статьи на Хабре - раз, два, три, четыре, пять.

Нет, каталог данных непереносим даже в пределах одной машины.

UPSERT

user - зарезервированное слово в PostgreSQL.

Идея дурацкая, если честно, но сделать можно:

create sequence shared_sequence;
create table production_data(id bigint default nextval('shared_sequence'), value text);
create table demo_data(id bigint default nextval('shared_sequence'), value text);

https://postgrespro.ru/docs/postgrespro/10/contrib...

Во-первых, работать напрямую с БД из Django - такая себе идея. Во-вторых, судя по симптомам, у вас где-то открываются соединения, но не закрываются. Небось ещё и потоки или асинхронность используете?

ORM его использует. А использовать его самому в Django проекте - это глупость, аннулирующая всю пользу от применения Django.

Очевидно, чтобы быстро находить по uuid.

Подойдёт.

Потому что сначала из последовательности берётся номер для id, а потом осуществляется вставка строки.