База данных на VPS: PostgreSQL или MySQL
База данных почти всегда упирается не в процессор, а в память и диск. Если рабочий набор данных помещается в кэш, запросы идут быстро даже на недорогом сервере, если нет — всё решает скорость диска. Разберём, как выбрать между PostgreSQL и MySQL, сколько памяти отдать базе, какой диск брать и как не потерять данные.
Для большинства сайтов и приложений выбор СУБД уже сделан за вас: WordPress, Битрикс и большинство PHP-движков рассчитаны на MySQL, многие проекты на Django, Rails и Go по умолчанию используют PostgreSQL. Если выбор свободен, обе базы справятся с типичной нагрузкой, а разница в том, что вам удобнее поддерживать и что умеет ваш стек.
PostgreSQL или MySQL
- MySQL и MariaDB — стандарт для CMS и интернет-магазинов на PHP. Их поддерживает любая панель управления и любой виртуальный хостинг, по ним больше готовых инструкций, а перенос сайта с хостинга на VPS обычно сводится к дампу и импорту.
- PostgreSQL — выбор для приложений со сложными запросами, отчётами и строгой целостностью данных. Он богаче по типам данных (JSONB, массивы, диапазоны), поддерживает расширения вроде PostGIS для геоданных и pgvector для векторного поиска.
Если проект новый и движок не диктует СУБД, берите ту, с которой знакома команда: на сервере с 4–8 ГБ памяти разница в скорости между ними меньше, чем разница между хорошо и плохо настроенной базой. Менять СУБД на работающем проекте дорого, поэтому решение принимают один раз.
Сколько памяти отдать базе
Обе СУБД держат часто используемые данные в собственном кэше, и его размер — главная настройка после установки. По умолчанию он маленький: 128 МБ у обеих, поэтому без настройки база на сервере с 8 ГБ памяти почти не использует её.
- PostgreSQL: по документации, на выделенном под базу сервере с 1 ГБ памяти и больше разумное начальное значение
shared_buffers— 25% памяти. Больше 40% выделять вряд ли полезно: PostgreSQL опирается ещё и на файловый кэш операционной системы. - MySQL (InnoDB): по документации MySQL 8.4, на выделенных серверах под буферный пул
innodb_buffer_pool_sizeчасто отдают до 80% физической памяти.
Ключевое слово в обоих случаях — «выделенный». Если на том же VPS работают веб-сервер, PHP-FPM, Redis и очереди, базе остаётся меньше: на сервере с 4 ГБ, где живёт и сайт, буферному пулу MySQL разумно дать 1–1,5 ГБ, а не 3. Остальное нужно процессам приложения и запасу, иначе сервер уйдёт в swap, и база станет медленнее, чем с маленьким кэшем.
Ориентир для размера сервера — объём «горячих» данных: таблиц и индексов, к которым обращаются постоянно. Если они целиком помещаются в кэш, большинство чтений не доходят до диска. По каталогу accsly.io на ноябрь 2026 года медианная цена VPS с 4 ГБ памяти — 1 839 ₽ в месяц, с 8 ГБ — 3 334 ₽, с 16 ГБ — 6 088 ₽, с 32 ГБ — 10 994 ₽. Подробнее о подборе памяти и ядер — в статье Сколько памяти и ядер нужно сайту, тарифы с памятью от 16 ГБ — на странице VPS с 16 ГБ RAM.
Диск и IOPS
Когда данные не помещаются в память, а также при каждой записи база обращается к диску мелкими случайными операциями. Здесь важен не объём и не линейная скорость из описания тарифа, а число операций ввода-вывода в секунду (IOPS) и задержка. NVMe выигрывает у SATA SSD именно на этих операциях, а жёсткий диск для рабочей базы не подходит совсем: он даёт сотни операций в секунду там, где SSD — десятки тысяч.
По каталогу accsly.io на ноябрь 2026 года NVMe указан в 41% из 29 603 тарифов VPS, и среди больших тарифов его доля выше: 38% у тарифов с 2 ГБ памяти и 45% у тарифов с 32 ГБ. Сравнение дисков — в статье NVMe или SSD, подборка тарифов — VPS на NVMe.
Цифры из описания тарифа на VPS — это верхняя граница: диск делят соседи по физическому серверу, а многие хостеры ограничивают IOPS на виртуальную машину. Реальную скорость проверяют после покупки утилитой fio с тестом случайного чтения и записи блоками по 4–16 КБ, пока сервер можно вернуть. Как это сделать в пробный период — в статье Как проверить пинг и скорость VPS до оплаты.
Бэкапы и реплики
Снапшот диска у хостера — удобная, но не самая надёжная копия базы: снимок, сделанный во время записи, может потребовать восстановления после сбоя, а хранится он обычно у того же хостера. Для базы делают собственные копии средствами СУБД:
- Логический дамп —
pg_dumpдля PostgreSQL илиmysqldumpдля MySQL. Для таблиц InnoDB дамп снимают с ключом--single-transaction, тогда, как сказано в документации mysqldump, он получается согласованным без блокировки таблиц. Подходит для баз до десятков гигабайт; восстановление большой базы из дампа может идти часами. - Восстановление на момент времени — полная копия файлов базы плюс непрерывный архив журнала изменений. В PostgreSQL это архивирование WAL, в MySQL — бинарный журнал. Так можно откатиться на минуту до ошибочного
DELETE, а не на вчерашнюю ночь.
Копии хранят вне сервера с базой — в объектном хранилище или на отдельном VPS в другом дата-центре — и регулярно проверяют восстановлением. Общие правила резервного копирования — в статье Резервные копии VPS, о хранилищах для копий — в статье Хранение файлов на VPS.
Реплика — вторая копия базы на другом сервере, которая получает изменения почти сразу: потоковая репликация в PostgreSQL, репликация в MySQL. Она позволяет быстро переключиться при отказе основного сервера и разгрузить его, отправив отчёты на реплику. Но бэкап она не заменяет: случайно удалённая таблица исчезнет и на реплике через доли секунды.
Управляемая база или своя на VPS
Облачные провайдеры предлагают управляемые базы: вы получаете адрес для подключения, а установку, обновления, бэкапы и реплики берёт на себя провайдер. Например, в Amazon RDS автоматические бэкапы хранятся до 35 дней с возможностью восстановления на момент времени.
- Управляемая база выгодна, когда в команде нет человека, готового отвечать за базу, когда нужна отказоустойчивость с автоматическим переключением или когда простой стоит дороже наценки. Минусы: та же память и диск стоят заметно дороже, чем на VPS, часть настроек и расширений недоступна, переезд к другому провайдеру сложнее.
- Своя база на VPS дешевле и даёт полный контроль над версией, настройками и расширениями. Взамен обновления, бэкапы, мониторинг места на диске и проверка восстановления — ваша работа. Подробнее о разнице подходов — в статье Облако или VPS.
Частый компромисс для небольшого проекта — база на том же VPS, что и сайт, с ежедневным дампом и архивом журнала в отдельное хранилище. Когда база вырастает до нескольких гигабайт «горячих» данных или начинает мешать приложению, её переносят на отдельный сервер с NVMe и закрывают порт базы от интернета, оставив доступ только с адресов приложения. Тарифы под такой сервер собраны на страницах VPS для PostgreSQL, VPS для MySQL и VPS для базы данных. Место на диске и задержку запросов стоит сразу добавить в мониторинг: переполненный диск — самая частая причина остановки базы.