Управляемый Postgres (managed) - выбор по умолчанию для многих команд. Но модель цен у serverless-баз (Neon, Supabase) и управляемых инстансов (Amazon RDS) построена на вычислениях, которые биллятся непрерывно, тогда как собственный PostgreSQL на VPS - это фиксированная месячная цена, которая не растёт вместе с нагрузкой.
В какой-то момент кривые пересекаются. Для стабильной всегда-включённой нагрузки один VPS с PostgreSQL и PgBouncer часто оказывается заметно дешевле управляемой базы аналогичного размера. Сравним: экономику, латентность и итоговую таблицу выбора.
Версии: у PG14 кончается поддержка
До сравнения цен - пара слов о версиях, потому что это напрямую влияет на свой вариант.
PostgreSQL поддерживает каждую мажорную версию пять лет после релиза.[1] PostgreSQL 18 - текущая стабильная линия (текущий минор 18.6),[1] релиз состоялся 25 сентября 2025 года.[1] PostgreSQL 14 вышел 30 сентября 2021 года и получает финальный поддерживаемый минор 12 ноября 2026 года.[1] После этой даты от проекта больше не будет багфиксов и исправлений безопасности,[1] так что держать 14-ю версию на своём сервере после ноября 2026 года - проблемы с безопасностью, а управляемые провайдеры всё равно вынудят с неё уйти.
Практический вывод: если ставите новый собственный инстанс в конце 2026 года, берите PostgreSQL 16 или 18 - обе комфортно внутри окна поддержки,[1] и заложите путь обновления по минорным версиям.
Чем модели цен реально отличаются
Ключевое различие - гранулярность биллинга.
Neon берёт плату за вычислительную единицу в час. Compute Unit (CU) - это примерно 4 ГБ RAM плюс CPU и SSD,[2] и вы платите за время работы вычислительного узла: на тарифе Launch $0.106 за CU-час, на тарифе Scale $0.222 за CU-час.[2] Когда compute приостанавливается (scale-to-zero), CU-часы перестают накапливаться, так что простой ничего не стоит.[2] Хранилище тарифицируется отдельно, $0.35 за ГБ в месяц,[2] а включённый исходящий трафик на платных тарифах - 500 ГБ на проект, дальше $0.10 за ГБ.[2]
Supabase берёт плату за подписку на план плюс compute за каждый проект. План Pro начинается от $25 в месяц, он включает квоты платформы и $10 в месяц кредита на compute, которые покрывают один проект на самом маленьком инстансе “Micro”.[3] Дополнительный или больший compute биллится за каждый проект сверх плана.[3] Один database-only проект на Micro-вычислении выходит в $25 в месяц до превышения включённых квот.[3] Free-тариф даёт 500 МБ базы и ставит проект на паузу после недели простоя; платные проекты не приостанавливаются.[3]
Amazon RDS биллит on-demand инстансы базы по часам, плюс хранилище и I/O.[4] Вы платите с момента запуска инстанса, с минимумом 10 минут за каждое изменение биллинга,[4] а Multi-AZ стандбай удваивают стоимость compute, потому что резервный инстанс работает постоянно.[4] У RDS есть free tier с 750 часами на Single-AZ инстансах в первый год,[4] что делает старт дешёвым, но дорогим после превышения лимита.
VPS - это фиксированная месячная цена. Droplets у DigitalOcean начинаются от $4 в месяц,[6] а Hetzner Cloud - один из самых дешёвых вариантов в Европе: Cost-Optimized от €5.99 в месяц (без НДС), Regular Performance от €6.49 в месяц.[5][7] Машины на 1 vCPU/2 ГБ в этом диапазоне спокойно тянут PostgreSQL с PgBouncer для небольшого или среднего приложения, и цена не меняется, простаивает сервер или загружен.
То есть управляемые провайдеры оптимизированы под эластичную, импульсную нагрузку, где платишь за потребление и можешь уйти в ноль. VPS оптимизирован под стабильную нагрузку: один предсказуемый счёт.
Компромисс: cold start и латентность
Цена serverless Postgres держится на том, что compute приостанавливается в простое, а приостановка создаёт холодные старты. Compute у Neon по умолчанию засыпает после пяти минут бездействия.[2] Первый запрос после пробуждения должен поднять compute заново, и это добавляет латентность ровно в момент, когда пользователь ждёт.
Собственный Postgres на VPS всегда включён. Нет пробуждения, нет cold start, а база находится в нескольких миллисекундах сетевой задержки от приложения, если оба живут на одной машине или в одном дата-центре. Сообщество сообщает о драматическом улучшении p95 после переезда с serverless и пулинга на локальный инстанс за пулером соединений: в одном из описаний p95-латентность упала с диапазона 900 мс до однозначных миллисекунд после перехода на собственный Postgres с PgBouncer в Docker.[8] Мы это на своём стеке пока не замеряли, так что относитесь к этому как к сигналу, а не к нашему бенчмарку, но направление согласуется с тем, как работает scale-to-zero.
Обратная сторона: если вам действительно нужно уходить в ноль ради того, чтобы не платить за простаивающую базу, managed создан именно для этого. И если приложение и база в разных регионах или нужна многоузловая отказоустойчивость, одиночный VPS подходит плохо, и тут правильный выбор - managed (либо правильно реплицируемый собственный кластер).
Зачем PgBouncer и как работает transaction pooling
Подключать приложение напрямую к Postgres нормально, пока клиентов немного. Каждое клиентское соединение съедает бэкенд-процесс и память на сервере, а у Postgres есть жёсткий лимит max_connections. PgBouncer встаёт перед Postgres и позволяет тысячам клиентов делить небольшое число реальных серверных соединений.
У PgBouncer три режима пулинга:[7]
- Session pooling (по умолчанию): серверное соединение закрепляется за клиентом на всё время подключения и возвращается в пул после отключения клиента.[7]
- Transaction pooling: серверное соединение закрепляется за клиентом только на время одной транзакции и возвращается в пул.[7] Именно это позволяет одному серверному соединению обслуживать множество одновременных клиентов, ведь большинство соединений между транзакциями просто простаивают.
- Statement pooling: серверное соединение возвращается после каждого запроса; это ломает семантику транзакций и редко бывает уместно.[7]
Transaction pooling - это режим, который реально решает проблему соединений. Поскольку соединение удерживается только на время транзакции, пул из, скажем, 20 серверных соединений способен обслужить сотни и тысячи простаивающих клиентов. Задокументированный размер пула по умолчанию на пару пользователь/база - 20, а максимум клиентских соединений - 100.[7]
Есть цена: в transaction pooling состояние сессии не сохраняется между транзакциями. SET, сессионные advisory locks и prepared statements работают не так, как в session-режиме, потому что каждая транзакция может выполниться на другом серверном соединении.[9] Большинство веб-приложений (REST/GraphQL API, короткие обработчики запросов) отлично работают в transaction pooling; долгоживущим интерактивным сессиям, опирающимся на состояние сессии, нужен session pooling.
Минимальная настройка PgBouncer
Классический файл - pgbouncer.ini. PgBouncer по умолчанию слушает порт 6432.[7] Минимальная конфигурация для включения transaction pooling:
[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb
[pgbouncer]
listen_addr = 127.0.0.1
listen_port = 6432
pool_mode = transaction
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
max_client_conn = 1000
default_pool_size = 20
Дальше укажите приложению 127.0.0.1:6432 вместо 5432, заполните /etc/pgbouncer/userlist.txt хешами паролей SCRAM или md5 и запустите PgBouncer командой pgbouncer -d /etc/pgbouncer/pgbouncer.ini.
Поскольку transaction pooling требует server_reset_query для очистки состояния сессии между клиентами, следите за настройкой server_reset_query в конфигурации PgBouncer и убедитесь, что конфиг Postgres позволяет пулеру управлять соединениями. Точные значения зависят от нагрузки, но сам режим - главное архитектурное решение.
И что это стоит на практике?
Сведём цифры рядом для небольшого всегда-включённого production Postgres с рабочим набором, скажем, 2 ГБ RAM, работающего 24/7.
| Вариант | Эффективная цена в месяц | Примечания |
|---|---|---|
| Supabase Pro, database-only, Micro compute | $25/мес[3] | Включает кредит $10 на compute; micro-вычисление покрывает базовый проект.[3] |
| Neon Launch, 2 CU всегда включено | ~$155/мес | 2 CU × 24 ч × 30 дней × $0.106/CU-ч ≈ $153 + хранилище.[2] |
| RDS Single-AZ, ~2 vCPU (класс db.t4g.small/medium) | инстанс по часам + хранилище[4] | Free tier покрывает только 750 часов в год.[4] |
| VPS Hetzner Cloud (свой PG + PgBouncer) | от €5.99/мес[5][7] | Плюс IPv4-адрес и ваше время на администрирование. |
| Droplet DigitalOcean (свой PG + PgBouncer) | от $4/мес[6] | 1 ГБ; для настоящей базы берите 2 ГБ. |
Цифра по Neon иллюстративна, а не котировка: она предполагает фиксированный всегда-включённый compute на 2 CU, то есть ровно тот паттерн, за который не платишь, если дать scale-to-zero. Если держать compute приостановленным между всплесками, счёт Neon сожмётся до хранилища. В этом вся его суть.
Смысл в том, что всегда-включённая база на 2 ГБ на VPS за $5-6 в месяц стоит долю от аналогичного всегда-включённого managed инстанса и при этом всегда тёплая. Managed выигрывает, когда нагрузка импульсная, непредсказуемая или когда вы вообще не хотите заниматься администрированием Postgres.
Таблица выбора
| Ваша ситуация | Лучший выбор |
|---|---|
| Стабильная всегда-включённая production-база, готовы вести VPS | VPS + PostgreSQL + PgBouncer |
| Нагрузка импульсная, и можно уходить в ноль | Managed (Neon/Supabase) |
| Хотите нулевое администрирование БД: бэкапы, патчи, всё из коробки | Managed |
| Нужны база и приложение рядом для минимальной латентности | VPS (та же машина или тот же DC) |
| Нужны мультирегион или управляемая репликация/HA | Managed либо реплицируемый свой кластер |
| Dev/staging с крошечными простаивающими базами | free-тарифы managed (Neon Free, Supabase Free) |
Для собственного production-пути PostgreSQL 16 или 18 вместе с PgBouncer в режиме transaction pooling на VPS за $4-6 - легитимная, более дешёвая альтернатива управляемой базе для стабильной нагрузки. Она стоит вашего времени на администрирование, и вы сами отвечаете за бэкапы, мониторинг и обновления. Когда это удобнее купить, чем вести самим, managed Postgres - правильная цена.
Источники
- PostgreSQL - Versioning Policy (поддержка мажорных версий, PG18 18.6 текущая, PG14 EOL 2026-11-12). https://www.postgresql.org/support/versioning/ - проверено 2026-10-31
- Neon - Pricing (определение CU, ставки CU-часа, scale-to-zero, хранилище, трафик). https://neon.tech/pricing - проверено 2026-10-31
- Supabase - Pricing (план Pro, кредиты на compute, free tier, политика паузы). https://supabase.com/pricing - проверено 2026-10-31
- Amazon RDS for PostgreSQL - Pricing (on-demand инстансы, почасовая оплата, минимум 10 минут, Multi-AZ, free tier, хранилище). https://aws.amazon.com/rds/postgresql/pricing/ - проверено 2026-10-31
- Hetzner Cloud (Cost-Optimized от €5.99/мес, Regular Performance от €6.49/мес). https://www.hetzner.com/cloud/ - проверено 2026-10-31
- DigitalOcean - Pricing (Droplets от $4/мес). https://www.digitalocean.com/pricing - проверено 2026-10-31
- PgBouncer - Config (listen_port 6432, pool_mode session/transaction/statement, default_pool_size 20, max_client_conn 100). https://www.pgbouncer.org/config.html - проверено 2026-10-31
- PgBouncer - Features (режимы пулинга, transaction pooling закрепляет серверное соединение только на время транзакции). https://www.pgbouncer.org/features.html - проверено 2026-10-31
- xsypher.com - “Why we moved from serverless postgres to self-hosted docker pgbouncer” (сигнал от сообщества по p95-латентности; не наши замеры). https://xsypher.com/article/why-we-moved-from-serverless-postgres-to-self-hosted-docker-pgbouncer-914ms-to-2ms-p95 - проверено 2026-10-31