Власний PostgreSQL на VPS: Уникайте тарифів керованих БД

Обчислення. Сховище. Збереження резервної копії.

Експорт знімка, про який ти забув. Плата за вихід з середовища підготовки, яке виконало ‘pg_dump’ минулого вівторка.

Ніхто не відкриває свій рахунок за керовану базу даних, чекаючи, що він буде дешевим.

Але, чорт.

Розрив між “Postgres за $25 на місяць” і тим, що з’являється на картці, став великим, і 4 GB VPS за ціну одного доповнення Supabase тепер обслуговує всю вашу базу даних з запасом місця для кешування активних сторінок ОС.

Самостійне розміщення виробничої бази даних Postgres вже не є оперативним кошмаром, яким воно було раніше. Репозиторій PostgreSQL Global Development Group (PGDG) надійний; сучасні інсталяції PostgreSQL (v14+) за замовчуванням використовують шифрування паролів SCRAM-SHA-256, а застаріле MD5 офіційно визнано застарілим починаючи з v18. Причини, через які люди залишаються на RDS, Supabase або Neon сьогодні, є оперативними, а не технічними.

Ми говоримо про реальні інвойси, реальні операційні витрати та те, як насправді виглядає сучасний хостинг Postgres.

Скільки Насправді Коштує Самостійне Хостинг PostgreSQL на VPS?

Самостійно розміщений PostgreSQL на 4 GB VPS зазвичай працює за частиною вартості, еквівалентної цінам RDS, Supabase Pro або Neon Scale, коли в структуру управління входять зберігання, резервні копії та вихідні обсяги.

PostgreSQL — це база даних, яку використовують 55,6% розробників, за даними Опитування розробників Stack Overflow 2025 року, найпопулярніша протягом останніх двох років. Це також база даних, яку ти можеш комфортно обслуговувати самостійно.

Порівняння для типового навантаження невеликої команди (4 ГБ RAM, ~100 ГБ даних, низький до помірного рівня запису, один регіон), ціни станом на травень 2026 року:

Опція	Обчислення	Сховище	Вихід за межі безкоштовного пакету	Найкраще для
Самостійно розміщено на 4 GB VPS	Фіксована ціна плану	Зазвичай включено	Зазвичай безлімітний або з високим лімітом	Стабільні робочі навантаження, команди, що віддають перевагу економії і зручні з Linux
AWS RDS db.t4g.medium	$47.45/місяць тільки обчислення	~$0.115/GB-місяць gp3	~$0.09/GB інтернет/за межами регіону	Команди, які бажають управління резервними копіями, аварійним відновленням та операціями в AWS
Supabase Pro	$25/місяць база + використання	$0.125/GB дискового простору бази даних понад включених 8 GB	$0.09/GB після 250 GB	Додатки, які потребують Postgres, автентифікації, сховища та реального часу в одному стеку
Neon Scale	$0.222 за CU/годину	$0.35 за GB/місяць	За використанням	Навантаження з різкими піками, що вимагають перегляду та розгалуження розробки

Ціна за годину для RDS db.t4g.medium на вимогу становить приблизно $0.065, або близько $47.45 на місяць лише за обчислення.

Додай 100 ГБ gp3 сховища за приблизно $0.115/ГБ-місяць та автоматичні резервні копії, і однозоновий сервер коштуватиме близько $60/місяць. Включення режиму Multi-AZ failover приблизно подвоює вартість обчислень, піднявши ціну конфігурації рівня продакшн до $100/місяць і вище.

Це не мала прогалина.

Самостійний хостинг дешевший, тому що ти виконуєш роботу, за яку раніше платила управлінська сторона. Дисципліна операцій, чергування, о 2-й годині ночі, коли диск заповнюється. Альтернатива управління базою даних, яку ти розглядаєш, може мати інший ціновий поріг наступного кварталу, тому проведи розрахунки своєї вартості перед зобов’язанням.

Коли Самостійний Хостинг PostgreSQL Має Сенс?

Самостійне розміщення PostgreSQL на VPS має сенс, коли в команді є базові знання Linux, стабільне навантаження, передбачуваний обсяг робіт та реальна причина уникнути рахунку за керований сервіс.

Це не працює, коли у тебе немає можливостей для операцій, регульованих вимог до високої доступності, які ти не можеш створити самостійно, або коли є поривчастий паттерн, який скористається миттєвим масштабуванням.

Три речі впливають на це рішення. Вартість, конфіденційність та суверенітет даних, а також контроль.

Де самостійне розміщення виграє беззаперечно:

• Стабільний трафік у єдиному регіоні з передбачуваним робочим набором.
• Малі та середні SaaS додатки з однією базою даних Postgres та командою, що знається на Linux.
• Робота з даними, що вимагають конфіденційності, де база даних не повинна знаходитися в оренді у сторонньої особи.
• Команди, які піклуються про витрати, чий рахунок за управління перевищив поріг операційних незручностей.

Там, де керований хостинг виграє беззаперечно:

• Завдання зі змінним навантаженням, яким потрібне миттєве збільшення та зменшення масштабу.
• Багаторегіональні налаштування, де глобальне реплікування є продуктом.
• Регульовані середовища, яким необхідні готові рішення HA, сертифікати відповідності та журнали перевірок.
• Команди без зайвих можливостей операційного управління і без планів їх розробки.

Часто згадується цифра економії від 40% до 60%. Датуйте її обережно.

Станом на 2021 рік, автор AWS Рупеш Десаї задокументував PostgreSQL на EC2, який працює на 40% до 60% дешевше, ніж RDS за еквівалентними специфікаціями, старіший за більшість сучасних сімейств інстансів RDS.

Поточна версія – аналіз витрат byteiota, опублікований наприкінці 2025 року, який стверджує, що RDS на 75% до 88% дорожче, ніж еквівалентне виділене обладнання.

Чесний розрахунок беззбитковості враховує години роботи, а не вартість сервера.

Як Обрати Правильний Розмір VPS для PostgreSQL?

Більшість продуктивних баз даних додатків комфортно працюють на 4 ГБ RAM з NVMe сховищем. Великі набори даних, велика кількість одночасних з’єднань або аналітичні завантаження збільшують вимоги до 8 ГБ або 16 ГБ і більше.

RAM визначає, скільки робочого набору Postgres може зберігати у пам’яті; коли гарячі сторінки починають використовувати диск, запити сповільнюються. NVMe має значення, оскільки Postgres чутливий до затримок випадкового читання гарячих сторінок та до пропускної здатності очищення для журналу перед записом.

Загальні рекомендації щодо налаштування сервера PostgreSQL починаються з:

• shared_buffers приблизно 25% від RAM системи.
• effective_cache_size приблизно 50%-75% від RAM системи.
• work_mem розміром консервативно — залежно від складності одночасних запитів, а не лише загального RAM.

На VPS з 4 GB це зазвичай означає виділення близько 1 GB для shared_buffers, залишаючи достатньо пам’яті для кешу сторінок Linux для зберігання часто використовуваних даних. Ця рівновага є частиною причини, чому скромна коробка з 4 GB може комфортно виконувати багато невеликих до середніх виробничих навантажень.

Карта плану до навантаження, яку тобі потрібно знати:

Рівень RAM	Типове навантаження	Рекомендований план стеку
2 GB	Середовища розробки, проекти з низьким трафіком	Нижче базового рівня
4 GB	Бази даних більшості продуктивних застосунків	Стек 4
8 GB	Більші набори даних, більше одночасних підключень	Стек 8
16 GB+	Postgres поряд з іншими важкими сервісами, аналітика	Стек 16

VPS Hosting DreamHost пропонує тобі доступ до Root, зберігання на NVMe та необмежену пропускну здатність з передбачуваним щомісячним рахунком.

Це чотири речі, від яких залежить саморозміщена робоча навантаження Postgres.

Як Встановити PostgreSQL На VPS?

Ти встановлюєш PostgreSQL на VPS у п’яти стислих кроках.

1. Настроювання VPS: Вибери тарифний план з достатньою кількістю RAM для робочого набору (базовий план Stack 4/4 GB). Ubuntu 24.04 LTS є рекомендованою ОС. Використовуй SSH з аутентифікацією за допомогою ключів, а не пароля.
2. Встановлення з офіційного репозиторію PGDG: Команда ‘apt install postgresql’ відстає за основними версіями. Додай репозиторій PGDG apt, а потім виконай ‘sudo apt install postgresql-18.’ Підтверди за допомогою ‘sudo systemctl status postgresql’
3. Встанови пароль postgres та створи роль для своєї програми: Виконай sudo -i -u postgres, потім psql, потім password postgres. Створи спеціалізовану роль з мінімальними привілеями: ‘CREATE ROLE myapp WITH LOGIN PASSWORD '...';’ та ‘CREATE DATABASE myapp_prod OWNER myapp;’
4. Правильно налаштуй прослуховувач: Відкрий /etc/postgresql/18/main/postgresql.conf. Встанови listen_addresses = ‘localhost’, якщо програма та база даних знаходяться на одному сервері, або прив’яжи до приватної IP-адреси, якщо програма працює на окремому VPS. Уникай прив’язки PostgreSQL до 0.0.0.0 на публічно доступному інтерфейсі. Відкриті інстанси PostgreSQL активно скануються та піддаються brute-force атакам автоматизованими ботами.
5. Захисти ‘pg_hba.conf’ та UFW: Редагуй pg_hba.conf, щоб дозволити доступ тільки необхідним IP-адресам програми з методом аутентифікації ‘scram-sha-256’. Налаштуй UFW, щоб дозволити порт 5432 тільки з цих IP-адрес. Використовуй SSH-тунель для адміністративних інструментів (і, будь ласка, не відкривай 5432 для публічного інтернету).

Спробуй це з іншого комп’ютера: psql -h <vps-ip> -U postgres.

Тайм-аут або відмова у з’єднанні від неавторизованої IP адреси зазвичай означає, що ваш слухач і правила брандмауера працюють належним чином. Запит пароля з публічного інтернету свідчить про те, що щось налаштовано неправильно. Як тільки Postgres запущено, конфігурація — це лише половина роботи.

Як Захистити PostgreSQL На VPS?

PostgreSQL на VPS захищається на трьох рівнях, плюс гігієна ролей і частота оновлення патчів.

1. Автентифікація: Використовуйте scram-sha-256 для нових інсталяцій та видаліть застарілі правила md5 з pg_hba.conf. Документація PostgreSQL зараз попереджає, що підтримка паролей, зашифрованих за допомогою MD5, застаріла і буде видалена в майбутньому релізі.
2. Мережа: Прив’яжіть PostgreSQL до ‘localhost’, приватної IP або інтерфейсу, доступного лише вашим серверам додатків. Уникайте прив’язки до публічно доступного інтерфейсу. Додатково використовуйте UFW та дозвольте порт 5432 лише з довірених IP додатків.
3. Шифрування в транзиті: Увімкніть TLS для будь-якого з’єднання, що перетинає межу мережі. Встановіть ssl = on в postgresql.conf, потім використовуйте правила hostssl … scram-sha-256 в pg_hba.conf, щоб клієнти не могли тихо повернутися до з’єднань без TLS. Самопідписані сертифікати прийнятні для внутрішнього трафіку, якщо клієнти правильно їх перевіряють.
4. Ролі: З’єднання додатків мають використовувати роль із мінімальними привілеями, необхідними лише для схем цього додатка. Суперкористувач призначений для міграцій та надзвичайних ситуацій.
5. Оновлення: Використовуйте репозиторій PGDG apt для актуальних пакетів PostgreSQL. Включіть незапитані оновлення безпеки для ОС, але плануйте оновлення PostgreSQL обережно, щоб несподіваний перезапуск не став вашою подією тижня. 

Твій перелік заходів безпеки:

• Використовуй тільки scram-sha-256; вимкни md5.
• Прив’яжи ‘listen_addresses’ до localhost або приватної IP-адреси.
• Правила UFW дозволяють 5432 тільки з довірених IP.
• SSL/TLS увімкнено для будь-якого з’єднання, що перетинає мережу.
• Додаток підключається з мінімально необхідними правами, ніколи як ‘postgres’.
• Увімкнено незаплановані оновлення безпеки.
• Ніде у ‘pg_hba.conf’ не має бути рядків ‘host all all 0.0.0.0/0 md5’.

Останній пункт є повчальною історією.

Публічний порт 5432 зі слабкими обліковими даними є відомою метою для криптомайнерів та атак методом “грубої сили”. Відкриті екземпляри PostgreSQL постійно скануються автоматизованими ботами, які шукають акаунти за замовчуванням, злиті паролі або дозвільні правила pg_hba.conf.

Публічно доступні екземпляри Postgres із слабкою автентифікацією часто компрометуються дивовижно швидко. База даних, відкрита безпосередньо для інтернету без належних мережевих контролів, TLS та ізоляції ролей, є тією помилкою, яка перетворюється на звіт про інцидент. Належно налаштована база даних все ще залишається за одну несправність диска від втрати даних.

Як Зробити Резервну Копію та Реплікувати PostgreSQL на VPS?

Резервне копіювання PostgreSQL на VPS використовує один з трьох механізмів, обраних на основі помилок, від яких ти хочеш захиститися. Логічні резервні копії через pg_dump для портативності, фізичні резервні копії через pg_basebackup плюс архівування WAL для відновлення до певного моменту часу, і потокова реплікація для високої доступності.

Логічні резервні копії використовуються для міграцій, часткових відновлень та оновлень розробки. Виконай pg_dump –format=custom –file=mydb.dump mydb_prod з щоденної Cron Job. Користувацький формат добре стискається і разом з директорійним форматом підтримує паралельне та вибіркове відновлення pg_restore. Перемісти дамп до об’єктного сховища поза VPS (DreamObjects, сумісне з S3).

Фізичне резервне копіювання управляє повним відновленням системи та відновленням до певного моменту часу. pg_basebackup разом з безперервним архівуванням Write-Ahead Log (WAL) дозволяє відновити дані на будь-який момент між останньою базовою резервною копією та найсвіжішим сегментом WAL, що є продуктивним рішенням, коли толерантність до втрати даних становить секунди, а не години.

Streaming реплікація є третім варіантом. Репліка для читання на другому VPS є гарячим резервом для навантажень з інтенсивним читанням або швидкою ціллю переключення при збоях. Налаштування реплікації бази даних вимагає другого VPS, але обмежує ваш найгірший випадок відключення до хвилин.

Механізм	Що Тобі Дає	Скільки Це Коштує
pg_dump + cron + зберігання поза VPS	Щоденне логічне резервне копіювання, портативне	Затримка відновлення, не точка в часі
pg_basebackup + архівація WAL	Фізичне резервне копіювання з відновленням в точці часу	Сховище та оперативна складність
Streaming replication	Гарячий резерв, майже нульова Recovery Point Objective (RPO), масштабування читання	Другий VPS плюс управління реплікацією

Щомісячне відновлення тесту. Керовані послуги включають усе це, і це є частиною того, що заощадження на самостійному хостингу компенсують. Якщо ти вже користуєшся керованим провайдером, шлях назад простіший, ніж здається.

Як Мігрувати З RDS, Supabase або Neon На VPS?

Ти мігруєш з керованого провайдера Postgres на VPS за чотири кроки.

1. Настроювання цільового VPS: Виберіть точну основну версію Postgres джерела. Встановіть PostgreSQL на новий VPS, слідуючи вищезазначеним крокам, потім попередньо створіть роль застосунку та базу даних.
2. Дамп з джерела: Виконайте pg_dump –format=custom –no-owner –no-privileges –file=src.dump <source-connection-string>. Опції –no-owner та –no-privileges видаляють специфічні для провайдера права ролей, які рідко коректно відновлюються на новому хості.
3. Відновлення на ціль: Виконайте pg_restore –dbname=myapp_prod –jobs=4 –no-owner –no-privileges src.dump. Слідкуйте за попередженнями про розширення. RDS, Supabase та Neon часто активують розширення, які можуть бути відсутніми у ванільному Postgres. Встановіть сумісні розширення з пакетів PGDG або postgresql-contrib перед відновленням.
4. Заміна та перевірка рядка підключення: Спочатку налаштуйте середовище підготовки на новий VPS, запустіть ваш набір тестів, після чого перевірте репрезентативні запити виробництва та потоки застосунків перед зміною рядка підключення виробництва. Для застосунків з низьким рівнем запису коротке вікно обслуговування під час остаточного переходу часто є простішим, ніж налаштування реплікації. Залиште джерельну базу даних онлайн і лише для читання на кілька днів як ціль для відкату.

Які зміни від провайдера?

1. З RDS: Специфічні ролі RDS (‘rds_superuser,’ ‘rdsadmin’) не існують у стандартному Postgres; –no-owner і –no-privileges вирішують більшість питань. Деякі розширення, керовані RDS, потребують ручної установки, а вихідний трафік з AWS під час дампу є платним.
2. З Supabase: Postgres у Supabase є справжнім Postgres, але рівні авторизації, сховища та периферії не мігрують. Схема вашого додатку мігрує. Замініть ці рівні на еквіваленти, що розміщуються самостійно, перед переходом.
3. З Neon: Гілкування зникає після міграції; плануйте резервні копії замість цього. Процес дампу та відновлення є простим, але оперативні звички, такі як миттєві гілки, потребують замінного робочого процесу.

Сама міграція зазвичай займає менше часу, ніж вибір тарифного плану VPS. Реалістичний час простою — кілька хвилин для маленьких баз даних, довше з відтворенням WAL для великих. Більшість установок закінчуються на цьому етапі, але є один сценарій, який змушує тебе йти далі…

Коли Варто Додати PgBouncer або Залишитися з Vanilla Postgres?

Більшість додатків на 4 GB VPS не потребують пулу підключень на початку. Додайте PgBouncer, коли кількість одночасних підключень перевищить приблизно 100, або коли ваш стек застосунків відкриває нове підключення на кожний запит.

З’єднання PostgreSQL є ресурсомісткими, оскільки кожне з них є повноцінним процесом операційної системи. З 4 ГБ оперативної пам’яті ти не хочеш мати сотні неактивних з’єднань, які споживають пам’ять. Пулер тримає дорогі з’єднання Postgres на своєму боці та надає дешеві, короткотривалі з’єднання твоєму додатку з іншого.

Два режими об’єднання мають значення:

• Пулінг сесій: Кожен клієнт отримує одне серверне з’єднання на сесію. Безпечно для будь-якого додатку, без зміни семантики, менший приріст пропускної здатності.
• Пулінг транзакцій: Кожен клієнт отримує серверне з’єднання на одну транзакцію. Великий приріст пропускної здатності. Втрачаються функції, які покладаються на стан сесії (підготовлені заявки, консультативні блокування, ‘LISTEN’/’NOTIFY’), якщо додаток не написаний з урахуванням цього.

Більшість малих SaaS додатків з пулом підключень ORM працюють нормально без PgBouncer, поки не виникає проблем. Сигналом того, що ви перетнули межу, є помилки ‘FATAL: too many connections’ або проблеми з пам’яттю через неактивні підключення.

Встанови його за допомогою sudo apt install pgbouncer, налаштуй /etc/pgbouncer/pgbouncer.ini зі своїм списком баз даних і режимом пулу, а потім націли додаток на PgBouncer на порт 6432.

Так, ти зрозумієш, коли це буде потрібно.

Прийняття Остаточного Рішення

Розрив в вартості достатньо значний, щоб виправдати проведення розрахунків за вашим власним рахунком. Але налаштування — це не найскладніша частина.

Складна частина – це операційна робота, яку покривав керований рахунок. Резервні копії, відновлення роботи, встановлення патчів та моніторинг.

Так чи інакше, зроби глибокий вдих перед тим, як відкрити наступну квитанцію.

Часті Запитання Про PostgreSQL На VPS

Скільки RAM потрібно PostgreSQL на VPS?

PostgreSQL працює на 1-2 ГБ для невеликих завдань та комфортно на 4 ГБ для більшості баз даних продуктивних додатків. Важчі набори даних, більша кількість одночасних з’єднань або аналітичні завдання збільшують вимоги до 8 ГБ або більше.

Чи можу я запустити PostgreSQL на VPS з 2 GB?

Так, ти можеш запустити PostgreSQL на VPS з 2 GB для невеликих застосунків, розробницьких середовищ та проектів із низьким трафіком. Обмеження в 2 GB залишає мало місця для кешування, тому продуктивність запитів падає, коли твої дані перевищують обсяг пам’яті. Для виробничих навантажень безпечнішим базовим рівнем є 4 GB.

Чи дешевше самостійно розміщувати PostgreSQL на VPS, ніж використовувати RDS або Supabase?

Так, самостійний хостинг PostgreSQL на VPS є дешевшим, ніж RDS або Supabase для більшості постійних робочих навантажень. 4 GB VPS зазвичай працює за частку відповідного RDS, Supabase Pro або Neon Scale, якщо врахувати сховище, резервні копії та вихідний трафік. Втім, компроміс полягає в тому, що ти сам керуєш базою даних.

Як безпечно відкрити доступ до PostgreSQL на VPS?

Не відкривай порт 5432 для загального доступу в інтернеті. Прив’яжи PostgreSQL до localhost або приватної IP, вимагай scram-sha-256 автентифікації та використовуй SSH-тунель для адмініструвальних інструментів замість відкриття 5432 до твого ноутбука. Публічний 5432 зі слабкою автентифікацією є відомою мішенню для криптомайнерів.

Чи потрібно мені використовувати Docker для PostgreSQL на VPS?

Ні, Docker не обов’язковий. Офіційний репозиторій PGDG apt встановлює PostgreSQL як рідний системний сервіс, що є найпростішою налаштуванням для виробничого середовища. Docker є розумним вибором, якщо ти вже використовуєш інші контейнери.

Як зробити резервну копію PostgreSQL на VPS?

Запускай pg_dump –format=custom за розкладом щоденних Cron Job і зберігай результат у сумісному з S3 об’єктному сховищі. Використовуй pg_basebackup разом з архівацією WAL для відновлення до певного моменту часу, коли втрата даних на кілька секунд має значення. Тестуй відновлення щомісяця.

Який план вибрати для самостійного хостингу PostgreSQL на DreamHost?

Тарифний план DreamHost VPS Stack 4 (4 GB RAM) є рекомендованим базовим рівнем для баз даних більшості виробничих додатків. Обери Stack 8 (8 GB) для більших наборів даних або високої конкуренції, та Stack 16 для Postgres поряд з іншими ресурсоємними сервісами.

Чи слід використовувати PgBouncer з PostgreSQL на маленькому VPS?

Більшість додатків на 4 GB VPS не потребують PgBouncer на початку. Додайте пулер підключень, коли одночасні підключення наближаються до 100, або коли ваш додаток відкриває нове підключення для кожного запиту.