Какую базу данных выбрать: Postgres, MySQL или SQL Server

Для нового приложения без ограничений используйте PostgreSQL. Он бесплатен при любом размере, следует стандартам, одинаково хорошо работает с реляционными данными и JSON-документами и имеет самый богатый набор расширений среди открытых баз данных. Используйте MySQL, когда его ожидает программа, которую вы запускаете, - WordPress, большинство PHP-приложений, множество плагинов для игровых серверов. Используйте SQL Server, когда строите на .NET с командой, которая его уже знает, или получаете в наследство уже существующую базу, и помните, что бесплатная редакция Express ограничена 10 ГБ на базу. Используйте MongoDB, когда ваши данные действительно имеют форму документов и приложение построено вокруг этого. А Valkey используйте рядом с любой из них, а не вместо: это быстрое хранилище в памяти для кэшей, сессий, очередей и ограничения частоты запросов, а не основная база данных.

Этот абзац - ответ для большинства. Остальная часть руководства объясняет рассуждения, чтобы вы могли понять, когда ваш случай - исключение.

Коротко, по задачам#

Самый важный столбец - третий. Базы данных редко выбирают по тестам производительности; их выбирают по тому, что уже предполагают ваша программа, ваш фреймворк и ваша команда. Борьба с этим стоит дороже любой разницы в производительности между ними.

PostgreSQL: вариант по умолчанию для новой работы#

PostgreSQL - открытая реляционная база данных с тридцатилетней историей разработки, свободной лицензией и без платной редакции. Её сильные стороны - широта и корректность: транзакционный DDL (неудавшаяся миграция чисто откатывается), богатые типы (массивы, диапазоны, jsonb, сетевые адреса), полноценные ограничения CHECK, оконные функции, обобщённые табличные выражения, частичные индексы и индексы по выражениям, а также система расширений, добавляющая целые возможности, - PostGIS для географии, pg_trgm для нечёткого текстового поиска, pgvector для эмбеддингов, TimescaleDB для временных рядов.

Отдельного упоминания заслуживает jsonb, потому что он устраняет самую частую причину, по которой люди хватаются за MongoDB. Можно хранить документ в столбце, индексировать его содержимое индексом GIN, запрашивать его операторами и при этом соединять с обычными таблицами в той же транзакции.

Издержки известны и управляемы. Каждое соединение - отдельный процесс операционной системы, так что сотни простаивающих соединений стоят реальной памяти, а приложению с множеством воркеров нужен пул соединений - это разбирает статья пулы соединений и лимиты. Многоверсионная архитектура оставляет мёртвые строки, которые должен вычищать autovacuum, и на интенсивно обновляемых таблицах это требует немного внимания. Ни то ни другое не повод выбирать что-то другое; и то и другое стоит понять в первый месяц.

Если вы выбираете именно между PostgreSQL и двумя его ближайшими соперниками, подробнее об этом - в статьях MySQL против PostgreSQL и Postgres или MongoDB.

MySQL: когда его ожидает программа#

MySQL - самая распространённая открытая база данных в вебе, во многом потому, что PHP вырос вместе с ней. WordPress, Drupal, Joomla, Magento, phpBB и подавляющее большинство PHP-приложений пишутся в первую очередь под MySQL. В мире игровых серверов плагины прав, плагины экономики и фреймворки вроде oxmysql для FiveM ожидают MySQL. Запуск такого ПО на чём-то другом - от неподдерживаемого до невозможного.

Современный MySQL - способная база данных. InnoDB уже больше десяти лет движок по умолчанию, с транзакциями, внешними ключами и устойчивостью к сбоям. MySQL 8 добавил оконные функции, обобщённые табличные выражения, полноценный словарь данных и намного лучшую поддержку JSON. MySQL 8.4 - выпуск с долгосрочной поддержкой, а это важно для базы, которую вы не хотите обновлять каждый квартал; кроме того, в нём по умолчанию отключён старый плагин аутентификации mysql_native_password, и именно это чаще всего ломает подключение старых клиентов. Подробности - в статье MySQL 8.4 LTS: что изменилось.

MySQL слабее PostgreSQL в деталях: меньше типов индексов, более слабая история с ограничениями CHECK, нетранзакционный DDL и длинный хвост исторических умолчаний - классический пример трёхбайтовая кодировка utf8, - о которых новым проектам нужно знать, чтобы их избегать. Используйте utf8mb4 везде. Для ПО, которое ожидает MySQL, всё это не важно; вы используете MySQL. Для нового приложения со свободным выбором именно поэтому обычно побеждает PostgreSQL.

SQL Server: .NET, существующая инфраструктура и потолок Express#

SQL Server - реляционная база данных Microsoft, и с 2017 года она работает на Linux так же, как на Windows. Её сильные стороны - инструменты и интеграция. SQL Server Management Studio по-прежнему лучший бесплатный графический клиент баз данных, оптимизатор запросов превосходен, планы выполнения и Query Store делают работу над производительностью необычайно наглядной, а весь стек .NET - Microsoft.Data.SqlClient, Entity Framework Core, ASP.NET Core Identity - считает её родной базой. T-SQL - способный процедурный язык, и команда, которая его знает, продуктивна на нём. Чем он отличается от открытых движков, разбирает статья основы T-SQL для разработчиков приложений.

Бесплатная редакция - Express, и её ограничения и есть всё решение:

Для огромного числа приложений - внутреннего инструмента, бизнес-приложения, небольшого SaaS, сайта игрового сообщества - 10 ГБ это годы данных, и Express - вполне годная рабочая база. Риск в том, что произойдёт, когда вы из неё вырастете. Следующая ступень - редакция Standard, которая лицензируется по ядрам и стоит реальных денег, в отличие от любой другой базы в этом списке. Выбирайте SQL Server ради его инструментов и вашей команды, а не по умолчанию, и честно оцените рост данных, прежде чем решиться. Где упирается потолок, разбирает статья хостинг SQL Server Express.

Если вы на .NET без существующего SQL Server, PostgreSQL через Npgsql - такой же полноценный выбор, только без потолка. Провайдеры сравнивает статья .NET с PostgreSQL, MySQL или SQL Server.

MongoDB: когда данные - действительно документы#

MongoDB хранит JSON-подобные документы (BSON) в коллекциях, без фиксированной схемы. Она подходит для данных, которые естественно вложены и читаются целиком, - товар с переменными атрибутами, профиль пользователя со встроенными настройками, содержимое события, - и для приложений, которые быстро меняют форму. Её конвейер агрегации мощный, драйверы приятные, а горизонтальное масштабирование через шардирование встроено, хотя небольшим проектам оно почти никогда не нужно.

Издержки проявляются, когда данные всё-таки оказываются реляционными. Соединения есть ($lookup), но MongoDB сильна не в них, поэтому данные, общие для многих сущностей, обычно дублируются в каждый документ, и затем их нужно держать синхронизированными. Транзакции по нескольким документам есть начиная с MongoDB 4.0, но только в наборе реплик или шардированном кластере: одиночный mongod их не поддерживает, и это важно, если вы на них рассчитываете. А «без схемы» на практике означает, что схема живёт в коде вашего приложения, где её труднее увидеть и обеспечить, - правила валидации на коллекциях помогают.

Полезная проверка: набросайте пять запросов, которые ваше приложение выполняет чаще всего. Если большинство из них достаёт один документ по ключу и показывает его, MongoDB подходит хорошо. Если большинство соединяет или агрегирует несколько видов сущностей, используйте PostgreSQL, а действительно переменные части положите в jsonb. Как проектировать для первого случая, разбирает статья индексы и проектирование схемы в MongoDB.

Valkey: вторая база, а не первая#

Valkey - хранилище ключ-значение в памяти, ответвлённое от Redis в 2024 году после того, как Redis сменил лицензию, и совместимое с протоколом, командами и клиентскими библиотеками Redis. Всё живёт в памяти, поэтому чтение и запись занимают микросекунды, а структуры данных - хеши, списки, множества, упорядоченные множества, потоки - прямо ложатся на типичные задачи:

• Кэширование результатов запросов или отрисованных фрагментов с TTL.
• Сессии веб-приложений, общие для нескольких процессов приложения.
• Очереди фоновых задач через библиотеки вроде BullMQ, Celery и Sidekiq.
• Ограничение частоты запросов с атомарными счётчиками, которые истекают.
• Таблицы лидеров на упорядоченных множествах.
• Pub/sub для передачи событий между процессами.

Она умеет сохранять данные на диск снимками и журналом только для добавления (append-only file), так что переживает перезапуск, но объём данных ограничен памятью, языка запросов нет, и она спроектирована в расчёте на то, что при исчезновении кэша ничего важного не теряется. Относитесь к ней как к месту для данных, которые можно восстановить или потерю которых можно пережить, рядом с реляционной базой, хранящей истину. Доводы за и против её добавления приводит статья Redis: когда он нужен, а об ответвлении рассказывает статья Valkey и Redis: в чём разница.

Что на самом деле решает#

Когда таблица выше не даёт ответа, его дают эти вопросы, примерно в таком порядке:

1. Чего ожидает программа? Если вы устанавливаете чужое приложение, используйте базу из его документации. Запуск WordPress на чём-то кроме MySQL или приложения для SQL Server на PostgreSQL - отдельный проект.
2. Что знает ваша команда? Команда, свободно владеющая T-SQL и SSMS, построит и будет эксплуатировать SQL Server лучше, чем PostgreSQL, который она освоила на прошлой неделе, и наоборот. Умение хорошо эксплуатировать базу - backup, восстановление, медленные запросы, обновления - важнее списка её возможностей.
3. Что ваш фреймворк поддерживает полноценно? Django и Rails склоняются к PostgreSQL; Laravel одинаково хорошо работает с MySQL и PostgreSQL; EF Core отлично работает с SQL Server и PostgreSQL.
4. Насколько большой она станет? Если можно предвидеть больше 10 ГБ данных, Express - неподходящий долгосрочный дом, если только вы не готовы позже платить за лицензию. У открытых движков такого потолка нет.
5. Насколько реляционны данные? Сильно реляционные данные говорят в пользу SQL-движков; независимые документы, читаемые целиком, - в пользу MongoDB.

Что не должно решать: графики тестов производительности, база, которую крупная компания использует для задачи, которой у вас нет, или желание не проектировать схему. Любая из этих баз справится с нагрузкой небольшого приложения на скромном железе, и любая вознаграждает за осознанно спроектированную схему.

Сменить базу позже можно, но редко дёшево. Переход между SQL-движками означает преобразование типов, переписывание запросов, использовавших особенности конкретного движка, и повторное тестирование всего; переход между MongoDB и реляционной базой означает перепроектирование модели данных. Один раз хорошо выбрать стоит того, чтобы потратить полдня на размышления.

Как запустить их в RE:NODE#

RE:NODE продаёт каждую из них как отдельный сервер: PostgreSQL, MongoDB, MySQL 8.4 LTS, Microsoft SQL Server 2022 Express на Linux и Valkey. К каждому подключаются по хосту и порту, указанным в тарифе, с учётными данными, сгенерированными для каждого сервера, а слота прокси в тарифах баз данных нет. Некоторые подробности:

• MySQL идёт с паролем root, базой приложения и пользователем приложения - всё сгенерировано.
• SQL Server - это редакция Express с паролем sa и созданной для вас базой, назначенной базой по умолчанию для sa; SSMS подключается по имени сервера host,port через запятую, а каждая база ограничена редакцией 10 ГБ.
• Valkey защищён паролем и сохраняет данные на диск и через AOF, и снимками.

Количество слотов backup зависит от линейки: от двух до шести у PostgreSQL и MongoDB, от одного до четырёх у SQL Server и MySQL и ноль или один у Valkey, где данные обычно - кэш, который можно восстановить. Цены начинаются примерно с $2 в месяц за самый маленький тариф Valkey и с $4-7 за реляционные и документные базы; актуальные цифры есть на странице хостинга баз данных. Что бы вы ни выбрали, делайте ещё и собственные логические backup - почему копия хостера никогда не должна быть единственной, объясняет статья backup и восстановление баз данных.

FAQ#

PostgreSQL лучше MySQL?

Для нового приложения со свободным выбором PostgreSQL обычно лучший вариант по умолчанию: строже, богаче возможностями и с транзакционными изменениями схемы. MySQL - лучший выбор, когда ваше ПО написано под него, а это большая часть мира PHP. Обе зрелые и достаточно быстрые почти для любого небольшого или среднего приложения.

Достаточно ли SQL Server Express для рабочей среды?

Да, в пределах его ограничений: 10 ГБ данных на базу, четыре ядра и около 1,4 ГБ памяти buffer pool. Многие бизнес-приложения годами спокойно живут в этих рамках. Честно планируйте рост, потому что шаг за пределы Express - это платная лицензия.

Стоит ли использовать MongoDB, чтобы не проектировать схему?

Нет. Схема всё равно существует; она просто переезжает в код приложения, где её труднее обеспечивать и менять. Выбирайте MongoDB, когда данные действительно имеют форму документов. Если нужно лишь несколько гибких полей, столбец jsonb в PostgreSQL даст это, не отнимая соединений и транзакций.

Может ли Valkey быть моей единственной базой?

Для одного лишь кэша, очереди или таблицы лидеров - да. Для основных данных приложения - нет: она ограничена памятью, не имеет языка запросов и соединений и спроектирована под данные, которые можно позволить себе восстановить. Используйте её в паре с реляционной базой, хранящей основную копию.

Можно ли сменить базу позже?

Да, но это проект, а не настройка. Меняются типы данных, запросы, миграции и тесты, а особенности конкретного движка приходится заменять. ORM сокращает работу, но никогда не устраняет её. Дешевле осознанно выбрать с самого начала.

Нужны ли небольшому приложению две базы?

Поначалу обычно нет. Одна реляционная база прекрасно справляется с сессиями, задачами и кэшированием небольшого приложения. Добавляйте Valkey, когда появится измеримая проблема - медленные повторяющиеся запросы, загруженная очередь задач, сессии, общие для нескольких процессов, - а не заранее.