Отдельный сервер под БД нужен, когда база мешает приложению или наоборот. Это снижает конкуренцию за CPU, RAM и диск, но требует продуманной сети и backup. Эта статья нужна не для выбора “самого большого” тарифа, а для подготовки заказа: какие компоненты разнести, какие метрики снять до оплаты и что проверить перед переносом production.
Когда подходит
- отдельный сервер под БД
- PostgreSQL/MySQL + приложение
- нагрузка растет быстрее, чем web слой
Практическая схема
- Соберите схему вокруг сценария: отдельный сервер под БД, PostgreSQL/MySQL + приложение, нагрузка растет быстрее, чем web слой. Отдельно опишите публичную точку входа, данные, фоновые задачи, backup и доступ администратора.
- Для приложения явно отделите web/runtime, database, cache, queue, uploads и secrets. Даже на одном сервере это должны быть разные сервисы и разные backup-пути.
- Не держите единственный backup на том же диске и в той же учетной записи, где работает основной сервис. Минимум: отдельный backup-путь, отдельный ключ доступа и понятный retention.
- Разделите доступы: публичные порты, SSH/VPN, панель управления, приватные сервисы и мониторинг. Все, что не должно быть доступно клиентам, закрывайте firewall до переноса.
Как выбрать ресурсы
- Начните с проверки: размер working set; IOPS и latency NVMe; репликация, backup и restore test.
- Для web/API снимите p95/p99 latency, RPS, worker count, очередь фоновых задач и slow queries. Эти метрики важнее общего числа посещений.
- CPU выбирайте по пиковому сценарию, а не по среднему idle. Для web/API смотрите RPS и worker count, для баз данных - slow queries и CPU wait, для игр - single-thread и tickrate.
- RAM считайте по рабочему набору: ОС, приложение, база/cache, панели, фоновые jobs и запас под пик. Если swap уже используется постоянно, тариф мал.
- Диск выбирайте по двум параметрам: объем через 3-6 месяцев и задержка/IOPS. Для БД, search, CI и backup важна не только емкость, но и скорость записи/чтения.
- Сеть считайте отдельно: месячный трафик, пиковый Mbit/s или Gbit/s, география пользователей, CDN/cache и требования к дополнительным IPv4.
Что выбрать в заказе
- OS - для обычного Linux-стека выбирайте актуальные Debian/Ubuntu; для панели проверьте совместимость панели с версией ОС; для нестандартного образа выбирайте Custom ISO и указывайте ссылку/требования в тикете.
- Локация - для VPS без GPU выбирайте NL, DE, RU, UK, USA или SG по latency и аудитории. Для GPU VPS локация фиксирована тарифом, для dedicated требования к региону лучше написать в тикет.
- IPv4 - дополнительные адреса или подсеть нужны для отдельных сервисов, RDNS, virtualization, reseller hosting, BGP или изоляции клиентов. Если заказываете подсеть под BGP, заполните ASN.
- Панель - cPanel/Plesk/Virtualizor добавляйте только если она реально нужна для управления клиентами, сайтами или виртуализацией. Для простого VPS часто достаточно SSH и автоматизации.
Проверка перед переносом
- Поднимите сервис на новом сервере как staging: та же ОС, версии runtime, база, расширения, панель и firewall-правила.
- Перед переносом проверьте login, оплату или основной API flow, отправку email, webhooks, cron/jobs и запись в базу под реальным пользователем.
- Сделайте backup до миграции, проверьте restore на тесте и заранее зафиксируйте rollback: DNS назад, старая база, остановка фоновых jobs или временная read-only пауза.
- Перед переносом снизьте DNS TTL, проверьте RDNS/hostname, SSL, cron, очереди, SMTP/webhook callbacks, monitoring alerts и доступ по аварийному каналу.
- Переключайте production только после проверки сети, диска, backup restore и основного пользовательского сценария: вход, заказ/оплата/API-запрос, запись в базу и уведомления.
Ошибки, которые ломают запуск
- держать uploads, database dump и единственный backup в одной директории приложения
- не проверять p95/p99 latency и slow queries до переноса
- выбирать тариф только по цене, не считая CPU, RAM, disk latency, backup, трафик и рост нагрузки
- переносить production без staging, backup restore и rollback-плана
- оставлять открытыми лишние порты или переносить старые firewall-правила без проверки
- забывать про DNS TTL, RDNS, SSL, cron, SMTP, webhooks, очереди, мониторинг и уведомления
- открывать тикет без версии ОС, панели, стека, IP/ASN требований, окна работ и ожидаемой даты запуска
Что написать в тикет
- версия PostgreSQL/MySQL
- размер базы
- нужна ли приватная сеть между app и database
