> и там кстате не только в ресурсах же проблема.

Именно в плане "репутации" (впечатлений пользовавшихся) коммерческих СУБД против бесплатных — это существенный фактор, мне кажется.

> попросить заоблачные мощности на сервер СУБД - любой может, много ума не нужно

Но не любой получит. :) И с PostgreSQL это произойдёт гораздо легче, нет?

> а почему СУБД вдруг начинает "чудить" не с того ни с сего

Мне кажется, такие истории я слышал "про всё".

> я бы не преуменьшал роль DBA на проектах

Я к тому, что преувеличивать тоже не стоит — stackoverflow "силами" подержанного PC из 2010-х ни один DBA (и даже все DBA и разработчики PostgreSQL вместе взятые) не поднимет. ;)

> (и тут даже Postgres возникает, зачастую, случайно),

И, кстати, тоже да. Мне вот недавно знакомый рассказывал, что их поставщики перевели поставляемый продукт с MS SQL Server Express (бесплатного, но с ограничениями) на PostgreSQL (что было причиной, я так и не понял).
И вот именно так:

> они что-то делают и проект выходит в свет.

и вышло — "первый блин комом". А "виноват", естественно, postgres. ;(

не совсем так. архитектура приложения и архитектура БД - скажем так по феншую построены. но проблемы все же возникают. и тут уже вопрос не в Oracle или не Postgres. вопрос наверно больше сможет ли тот же Postgres на тех же серверных мощностях то же самое сделать

А у меня встречный вопрос — почему PostgreSQL должен быть на тех же серверных мощностях?
Может, их можно сильно увеличить, и намного выиграть, например (и, в том числе, по TCO)? ;)

позволю себе поворчать: в 90% случаев “по феншую” — это как удобно в ORM/фреймворке.
сколько раз встречал ситуации, когда запрос можно ускорить на 2-3 порядка, но это требует нестандартной конструкции и поэтому рекомендации уходят в долгий ящик.

но да, пару раз встречал грамотные проекты, где не было детских проблем, прям совсем. как вы говорите — по феншую…

ну это конечно интересно. а насколько нужно увеличить? на 10-20% или на порядок в 2-3 раза?

Как вообще можно рассуждать о сравнительной производительности неведомой базы данных в вакууме? ;)
Это сравнивать нужно, тестировать.

> на 10-20% или на порядок в 2-3 раза?

А почему не на минус 20-30%, или в 0.2-0.3 раза, а? ;)

да у нас ORM. и как обычно "детские" болезни - это выборка из БД. но это нам не мешает. работало и работало. все тугие запросы в СУБД раньше отладили. но вот раз в 2-3 месяца СУБД начинает "чудить". и тогда DBA очень нехватает...

купите пакет консультационных часов и расходуйте их по необходимости.
да, первые 3-4 часа улетят, т.к. надо разбираться в том, что у вас есть. зато потом как по маслу пойдёт!

Скромный вопрос.
ORM ругается на то что запрос не корректен, хотя ровно тот же запрос на sqlite выполнялся без особых вопросов.
Это ORM попусту возникает или в PostgreSQL такой запрос действительно не выполнится?

Текстом показывайте. Но скорее всего да, вряд ли Вы сходу нашли bug в postgres. ;)

Текстом вручную запрос был такой:

SELECT
 CASE WHEN m.to_id = ?
   THEN sender.id
   ELSE receiver.id
 END interlocutor,
 CASE WHEN m.to_id = ?
   THEN sender.name
   ELSE receiver.name
 END username,
 sender.id msg_sender_id,
 m.text msg_text
FROM messages m
JOIN users sender ON
 sender.id = m.from_id
JOIN users receiver ON
 receiver.id = m.to_id
WHERE m.to_id = ? OR m.from_id = ?
GROUP BY interlocutor
HAVING m.id = max(m.id)
ORDER BY m.id DESC

Могу со скрина запрос набрать, если так принципиально)

Ну и он явно неправильный.
Т.е. в select list есть много чего без агрегации, чего нет в GROUP BY (да и в HAVING, и в ORDER BY).

Если Вам не принципиально, чтобы Вам помогали — не набирайте. ;)

compiler.py:362 - кмк говорит о том что запрос заглох даже не улетев в постгрес

вот я хотел выделить текст ошибки, но как мне сделать с вашего скриншота? ))

Есть же слова👌
Можно сказать где именно то на что вы хотели обратить внимание)

P.S. По ссылке из ошибки уже ходил
P.P.S. ORM - sqlalchemy v1.4.0b3, если это важно

interlocutor из какой таблицы?

Да вот так же — https://ms-paint-i.de/ (какие-то мы тут несовременные, в самом деле). :)