Вывод #4: И MySQL, и PosgreSQL легко вывозят “простые” 1.000.000 RPS c “сравнимым” перфомансом.

В последние годы ряд исследователей замечали, что PostgreSQL свой перфоманс системно “подтягивает”, в то время как перфоманс MySQL пусть медленно, но заметно деградирует (см. посты Mark Callahan, например, на его сайте https://smalldatum.blogspot.com/).

Наши результаты с этим расходятся (см. ссылку на исследование внизу или картинку в первом комментарии).
По двум причинам:
1) мы взяли специфическую Read-Only нагрузку с компактными данными, “симулирующую” работу кешей.
2) мы собирали MySQL/MyDB со специализированными настройками, которые практически нивелируют проблему увеличения “InnoDB code bloat”. Интересно было бы “перепрогнать” тесты Марка на таких сборках и убедиться, что этот эффект будет виден и на других нагрузках.

Без оптимизаций ванильный MySQL проигрывает по производительности PosgtreSQL на low concurrency workloads (число одновременных соединений << 1000). Но уже при числе одновременных соединений 3000+ пропускная способность MySQL начинает опережать пропускную способность PosgtreSQL. А с оптимизациями на всем диапазоне MySQL показывает производительность лучше, чем PosgtreSQL. Замечу, что если в продакшене у вас что-то типа баунсера, то производительнсть связки постгрес+баунсер будет ещё ниже (для MySQL, напомню, баунсер не нужен).

Является ли это критичным, говорит ли это о том, что нужно выбирать MySQL, а не PostgreSQL? Ни в коем случае! Речь идёт о миллионе запросов в секунду, характер нагрузке специфичный. Но это хорошая иллюстрация того, что обе СУБД, и MySQL, и PostgreSQL достаточно хорошо ведут себя на таких нагрузках.

Для справки:
- Исследование PostgreSQL/MySQL/Redis/Valkey/Memcached (HighLoad MSK-2024)
- Вывод #1 (Робкое напоминание о железе и гибридном подходе)
- Вывод #2 (PostgreSQL “сгладил” родовую травму)
- Вывод #3 (Valkey “сгладил” родовую травму Redis)