Скорее всего, это не PostgreSQL, это ваш дизайн. Смена обуви, скорее всего, не сделает вас лучшим танцором.
Знаете ли вы, что вызывает медлительность? Это утверждение, время для обновления индексов, время поиска?
Все 5000 пользователей пытаются записать данные в таблицу пользователей в то же самое время, когда вы пытаетесь вставить 5001-го пользователя? Я верю, что это может вызвать проблемы. Возможно, вам придется пойти с чем-то настроенным на обработку экстремального параллелизма, например с Oracle.
MySQL (как мне сказали) можно оптимизировать для более быстрого чтения, чем PostgreSQL, но оба они довольно смехотворно быстры с точки зрения количества поддерживаемых транзакций в секунду, и это не похоже на вашу проблему.
P.S.
У нас было небольшое обсуждение в комментариях к другому ответу - обратите внимание, что некоторые из самых больших в мире баз данных с хранилищем реализованы с использованием Postgres (хотя они имеют тенденцию настраивать внутренние компоненты движка). Postgres очень хорошо масштабируется для размера данных, для параллелизма лучше, чем для большинства, и очень гибок в плане того, что вы можете с ним сделать.
Хотелось бы, чтобы у вас был лучший ответ, спустя 30 лет после изобретения технологии, мы должны быть в состоянии заставить пользователей иметь менее подробные знания о системе, чтобы она работала бесперебойно. Но, увы, для всех продуктов, которые я знаю, требуются обширные размышления и настройки. Интересно, могли бы создатели StackOverflow рассказать, как они справились с параллелизмом и масштабируемостью БД? Они используют SQLServer, я знаю это очень много.
P.P.S.
Так что, по случайности, я вчера столкнулся с проблемой параллелизма в Oracle. Я не совсем уверен, что я прав, не будучи администратором базы данных, но ребята объяснили это примерно так: у нас было большое количество процессов, подключающихся к базе данных и проверяющих системный словарь, что, по-видимому, вызывает короткую блокировку. Несмотря на то, что это просто чтение. Синтаксический анализ запросов делает то же самое ... поэтому у нас (в многотеразонной системе с тысячами объектов) было много вынужденных ожиданий, потому что процессы блокировали друг друга из системы. Наш системный словарь также был чрезмерно большим, потому что он содержит отдельную копию всей информации для каждого раздела, которых может быть тысячи на таблицу. На самом деле это не имеет отношения к PostgreSQL, но необходимо сделать следующее: помимо проверки вашего проекта, убедитесь, что ваши запросы используют переменные связывания и используются повторно, а нагрузка на общие ресурсы минимальна.