Выбор между MySQL и PostgreSQL нельзя сводить к объёму RAM, но в обоих случаях memory budget нужно продумать до production. Плохая практика - отдать базе почти всю память и забыть про OS, web workers, connections и maintenance jobs.
Начнём с чистого бюджета VPS на 8 GB
Все 8 GB не принадлежат database. Сначала оставьте headroom для OS и системных services, затем учтите application processes. Только после этого планируйте cache, buffers и connection-related memory.
MySQL - buffer pool важен, но не единственный фактор
InnoDB buffer pool часто является крупным потребителем памяти. Его размер зависит от того, работает ли MySQL на отдельном VPS или делит VM с web stack. Увеличение `max_connections` не создаёт дополнительные ресурсы.
PostgreSQL - shared_buffers не показывает всю картину
Рассматривайте `shared_buffers`, connection count, operation memory и OS page cache вместе. Особенно осторожно планируйте `work_mem`, потому что один сложный query может одновременно выполнять несколько sort/hash operations.
Memory-planning worksheet
| Вопрос | Почему это важно |
|---|---|
| DB на отдельном VPS? | большую долю RAM можно отдать базе |
| Сколько active connections? | connection overhead |
| Каков размер dataset? | cache strategy |
| Какой тип queries? | OLTP и analytics отличаются |
| Когда идут backups? | конкуренция за ресурсы в peak |
материал о выборе сервера для большой базы данных подробнее разбирает sizing. Для Laravel полезен гайд по хостингу Laravel, где видна связь application и DB layers.
Какую базу выбрать?
Если приложение и команда уже зависят от конкретной database, миграция только потому, что другая якобы «быстрее», редко оправдана. Оцените нужные features, tooling, query patterns и опыт команды.
Для полного database administration подходит Unmanaged VPS. Для выбора ресурсов смотрите SERVER1 VPS. Перед production-изменениями проведите load test и проверьте backup/restore.
Dedicated DB VPS и shared web+DB VPS нельзя настраивать одинаково
Если database работает на отдельном VPS, большую долю RAM можно отдать cache, потому что PHP, Node и web server больше не конкурируют на той же VM. На общем сервере такой же aggressive setting может привести к swap. Поэтому советы вида «выделите базе X% RAM» нельзя применять без контекста.
Connections часто недооценивают при memory planning
100 разрешённых connections не означают, что вам постоянно нужны 100 активных queries. В некоторых приложениях connection pool или proxy позволяет обслуживать больше application requests меньшим количеством реальных DB sessions. Сначала измерьте active connections, transaction duration и waiting states.
Разные workload требуют разных метрик
| Workload | Что особенно измерять |
|---|---|
| Transactional web app | latency, locks, indexes, active connections |
| WooCommerce / CMS | query count, slow queries, object cache, concurrency |
| Reporting / analytics | large scans, temporary memory, I/O, execution plans |
| Background imports | write bursts, lock time, redo/WAL growth |
Ловушка benchmark «MySQL vs PostgreSQL»
Одинаковая schema/query не всегда даёт честное сравнение: optimizers, indexes, data types и типичные query idioms различаются. Если migration реальна, тестируйте production workload, а не один synthetic query.
Monitoring baseline до tuning
- CPU и disk latency;
- active/waiting connections;
- cache-hit behavior;
- распределение slow queries;
- locks/deadlocks;
- backup duration и maintenance impact.
Правильная database - не та, которая популярнее, а та, которая лучше соответствует feature requirements, query patterns и опыту команды.
