ElenaVolkov
New member
За последние пять лет я успел поработать и с PostgreSQL, и с MongoDB на проектах, где счёт шёл на десятки тысяч запросов в секунду, и каждый раз вопрос выбора вставал ребром. В 2025 году спор «реляционка против документной базы» уже не выглядит как религия: обе системы сильно выросли, обе научились тому, чего раньше не умели, и теперь всё решает конкретика задачи, а не мода и не вкус тимлида.
За PostgreSQL я держусь там, где важны строгие гарантии и сложная аналитика. Партиционирование по времени, логическая репликация, покрывающие индексы, jsonb для гибких полей, зрелый планировщик запросов и пулер соединений вроде PgBouncer — всё это позволяет вытянуть очень серьёзную нагрузку без экзотики. На одном из проектов мы спокойно держали пик около тридцати тысяч чтений в секунду на репликах, а запись шла через партиции и не блокировала горячие таблицы. Ещё один плюс, который я оценил по-настоящему: когда что-то идёт не так, у Postgres огромное сообщество и понятная диагностика, и ты почти никогда не остаёшься один на один с проблемой.
MongoDB я выбираю в другой ситуации: когда схема данных реально плавает, документы разной формы, а нагрузка в основном на запись и её нужно размазать по кластеру. Шардирование из коробки, быстрые вставки, change streams для реакций на изменения и удобная работа с вложенными структурами — тут она хороша. Я строил на ней сервис событий и логов, и это работало как часы, пока мы не начали делать тяжёлые агрегации по огромным коллекциям и многошаговые транзакции. Вот здесь начинается боль: рабочее множество не влезает в память, индекс раздувается, а крос-шардовые операции стоят дорого и по времени, и по нервам.
Отдельно расскажу про свою самую болезненную ошибку. Мы выбрали ключ шардирования по монотонно растущему полю и в итоге получили один горячий шард, который принимал почти всю запись, пока остальные скучали. Спаслись составным ключом с хешированной частью и предварительным разбиением диапазонов. Вывод, который я вынес на всю жизнь: у MongoDB 90 процентов успеха — это правильно выбранный ключ шардирования ещё до того, как в базу попали первые реальные данные. Переделать это на живой системе с высокой нагрузкой почти нереально.
Если сравнивать по эксплуатации, то PostgreSQL мне кажется более предсказуемым: одна команда, понятные бэкапы, знакомые метрики, огромный выбор managed-решений. MongoDB требует дисциплины и понимания внутренностей — состояния репликасета, балансировки чанков, поведения WiredTiger под нагрузкой. Это не минус, но это отдельная компетенция, которую нужно либо иметь в команде, либо закладывать в бюджет на поддержку.
Мои рекомендации читателям просты. Если у вас транзакции, отчёты, целостность и связи между сущностями — берите PostgreSQL и не усложняйте себе жизнь. Если у вас поток событий, разнородные документы и честная горизонтальная запись — смотрите в сторону MongoDB, но сначала нарисуйте ключ шардирования. И почти никогда не стоит выбирать «на вырост»: обе базы прекрасно сосуществуют, и гибридный подход, когда горячие документы лежат в одной системе, а аналитика и связи в другой, в 2025 году абсолютно нормален. Не верьте бенчмаркам из интернета — прогоняйте свой реальный профиль нагрузки, потому что разница между синтетикой и продакшеном огромна.
А какой стек вы держите под высокой нагрузкой в 2025 году и что стало решающим аргументом в пользу вашей базы — приглашаю поделиться опытом в комментариях, уверен, у каждого найдётся своя история с горячим шардом или неожиданно быстрым запросом!
За PostgreSQL я держусь там, где важны строгие гарантии и сложная аналитика. Партиционирование по времени, логическая репликация, покрывающие индексы, jsonb для гибких полей, зрелый планировщик запросов и пулер соединений вроде PgBouncer — всё это позволяет вытянуть очень серьёзную нагрузку без экзотики. На одном из проектов мы спокойно держали пик около тридцати тысяч чтений в секунду на репликах, а запись шла через партиции и не блокировала горячие таблицы. Ещё один плюс, который я оценил по-настоящему: когда что-то идёт не так, у Postgres огромное сообщество и понятная диагностика, и ты почти никогда не остаёшься один на один с проблемой.
MongoDB я выбираю в другой ситуации: когда схема данных реально плавает, документы разной формы, а нагрузка в основном на запись и её нужно размазать по кластеру. Шардирование из коробки, быстрые вставки, change streams для реакций на изменения и удобная работа с вложенными структурами — тут она хороша. Я строил на ней сервис событий и логов, и это работало как часы, пока мы не начали делать тяжёлые агрегации по огромным коллекциям и многошаговые транзакции. Вот здесь начинается боль: рабочее множество не влезает в память, индекс раздувается, а крос-шардовые операции стоят дорого и по времени, и по нервам.
Отдельно расскажу про свою самую болезненную ошибку. Мы выбрали ключ шардирования по монотонно растущему полю и в итоге получили один горячий шард, который принимал почти всю запись, пока остальные скучали. Спаслись составным ключом с хешированной частью и предварительным разбиением диапазонов. Вывод, который я вынес на всю жизнь: у MongoDB 90 процентов успеха — это правильно выбранный ключ шардирования ещё до того, как в базу попали первые реальные данные. Переделать это на живой системе с высокой нагрузкой почти нереально.
Если сравнивать по эксплуатации, то PostgreSQL мне кажется более предсказуемым: одна команда, понятные бэкапы, знакомые метрики, огромный выбор managed-решений. MongoDB требует дисциплины и понимания внутренностей — состояния репликасета, балансировки чанков, поведения WiredTiger под нагрузкой. Это не минус, но это отдельная компетенция, которую нужно либо иметь в команде, либо закладывать в бюджет на поддержку.
Мои рекомендации читателям просты. Если у вас транзакции, отчёты, целостность и связи между сущностями — берите PostgreSQL и не усложняйте себе жизнь. Если у вас поток событий, разнородные документы и честная горизонтальная запись — смотрите в сторону MongoDB, но сначала нарисуйте ключ шардирования. И почти никогда не стоит выбирать «на вырост»: обе базы прекрасно сосуществуют, и гибридный подход, когда горячие документы лежат в одной системе, а аналитика и связи в другой, в 2025 году абсолютно нормален. Не верьте бенчмаркам из интернета — прогоняйте свой реальный профиль нагрузки, потому что разница между синтетикой и продакшеном огромна.
А какой стек вы держите под высокой нагрузкой в 2025 году и что стало решающим аргументом в пользу вашей базы — приглашаю поделиться опытом в комментариях, уверен, у каждого найдётся своя история с горячим шардом или неожиданно быстрым запросом!