Но минус - да, связанные руки в плане возможностей SQL

понял, спасибо

там еще проблемы от индексов частенько возникают, и в орм с этим  бывает туговато, как и с анализом запросов

Не очень понял, какие проблемы с индексами. Индексы с ORM вообще никак не связаны. А что касается анализ запросов, то у любой ORM есть возможность вывода запросов текстом в stdout или в логи. Если внезапно такой возможности нет (я такие ORM правда не встречал), то всегда можно включить логи запросов на уровне PostgreSQL. При локальной разработке просто включаете этот вывод, смотрите SQL запрос и проверяете его через EXPLAIN (ANAYLYZE, BUFFERS)... Соответственно, если нужны индексы, то делаете миграцию с созданием нужного индекса. То есть индексы никак не связаны с ORM или квери-билдерами. Единственное, в Django есть всякие db_index=True на уровне моделей (это использовать не обязательно, кстати), которые позволяют автоматически генерировать миграции для создания индексов. Но работает это лишь в очень простых случаях.

а ты эти запросы видел? там жесть че бывает

я долбался с ними и это было больно

Смотря как пользоваться ORM. Если юзать всякие findBy и лэзи-лоадинг, то, конечно, жесть. Если использовать квери-билдер, то такой проблемы нет, ведь явным образом запрос строится select(...)->where(...)->leftJoin(...)...

А строку конкатенировать руками, когда фильтров 20 опциональных, не больно?)

если вместо орм юзать квери билдер, то никакой разницы с скл нет, кроме того, что тебе требуется выучить еще один весьма ограниченный язык нотации этого билдера вместо скл.

ну и разгрести костыли вставленные братишками когда этого языка было не достаточно

Разница есть очень большая. Во-первых, есть маппер на объекты, во-вторых, нет боли и страданий, когда куча опциональных условий фильтрации (например, список товаров интернет-магазина), как я уже выше писал. В-третьих, если у вас несколько проектов используют одну базу данных, модели ORM можно вынести в библиотеку и подключать к нужным проектам. Тогда при переименовании столбцов в БД вам не придётся в каждом проекте все запросы исправлять вручную - достаточно просто обновить зависимости.

а если идёт запрос с условием: по_индексу AND не_по_индексу, то это стирает всё преимущество, которое даёт индекс?

Если запрос не_по_индексу это просто проверка boolean флага, то это никак не меняет картину?

Что-то моя база данных сломалась. Создаются поля в таблице для чтения даже под posgres (superuser). Помогите, пожалуйста, решить проблему.

что значит "таблица для чтения" ?
этот как ?

Нужны детали, или страдай

Любая создаваемая таблица, поля в которой только для чтения.

Зачем ты этих скринов понапихал?

Для деталей