Я деплоїв продакшн-Postgres на всі три. Supabase для двох клієнтських проєктів, Railway для одного, Neon для свого сайту та двох невеликих клієнтських застосунків. У кожного є світ-спот — і ціновий обрив, де він перестає мати сенс.
Це не порівняння фіч. Таких повно. Це цінова математика з реальних проєктів, із підводними каменями, які я зловив і які маркетингові сторінки не згадують.
Коротка версія
| Supabase | Railway | Neon | |
|---|---|---|---|
| Краще для | Auth + Postgres + storage в одному рахунку | Простий деплой, передбачувані ціни | Serverless-застосунки, гілкування, сайти з низьким трафіком |
| Безкоштовний тариф | Щедрий (2 проєкти, 500MB) | $5/міс кредит | Щедрий (0.5 GiB зберігання, 190 compute-годин) |
| Модель ціноутворення | Тарифні плани | За споживанням (compute + storage) | За споживанням (compute-години + storage) |
| Ламається при | Високій кількості з'єднань, великому файловому сховищу | Високотрафікових застосунках (стрибки CPU-білінгу) | Стійких висококонкурентних навантаженнях |
| Вартість міграції | Середня (якщо використовуєш Auth/Storage) | Низька (просто Postgres) | Низька (просто Postgres) |
Supabase: пакетна пропозиція
Supabase дає Postgres + Auth + Storage + Edge Functions + Realtime в одному дашборді. Якщо потрібне все це — цінність виняткова. Pro-план за $25/місяць покриває багато.
Де я використовував: Два клієнтські проєкти — B2B SaaS з авторизацією, завантаженням файлів та real-time presence. Supabase був правильним вибором, бо альтернатива — склеювати Auth.js + S3 + окремий Postgres-хост + WebSocket-сервер. Supabase об'єднав усе.
Де дорожчає:
-
Ліміти з'єднань. Безкоштовний тариф дає 60 прямих з'єднань. Pro-план дає більше, але connection pooling (через Supavisor) має свої ліміти. Якщо в тебе Next.js із serverless-функціями, кожен виклик функції відкриває з'єднання. При 50 конкурентних користувачах можна впертися в стелю пулу. Рішення — PgBouncer або Supavisor у transaction mode — але тоді не можна використовувати
LISTEN/NOTIFYта підготовлені запити між транзакціями. -
Bandwidth сховища. Supabase Storage зручний, але не дешевий у масштабі. Роздача 100GB/місяць файлових завантажень на Pro коштує більше, ніж покласти ті самі файли на Cloudflare R2. Для одного клієнта ми перенесли роздачу файлів на R2 після того, як рахунок за storage подвоївся в місяць 3.
-
Compute-аддони. Якщо переріс shared Postgres-інстанс, dedicated compute починається з $50/місяць і росте швидко. 4-ядерний інстанс — $100/місяць — на цьому рівні ти вже в території Railway/Render із меншою гнучкістю.
Питання lock-in: Якщо використовуєш Supabase лише для Postgres — міграція проста, це стандартний Postgres. Якщо використовуєш Auth + Storage + RLS-політики + Edge Functions — ти побудував на платформі. Міграція означає заміну 4 сервісів, не 1.
Цінові пороги Supabase
| Сценарій | Місячна вартість | Нотатки |
|---|---|---|
| Solo-розробник, 1 проєкт, низький трафік | $0 | Безкоштовний тариф щедрий |
| SaaS MVP, <1K користувачів, помірне сховище | $25 | Pro-план покриває |
| Зростаючий SaaS, 5K користувачів, 50GB сховища | $75–$150 | Compute-аддони вмикаються |
| Високий трафік, 20K+ користувачів | $300+ | Розглянь dedicated Postgres |
Railway: простий шлях
Railway — найближча штука до «просто задеплой». Пушиш код — Railway запускає. Postgres — плагін: клікнув, додав, отримав рядок підключення.
Де я використовував: Один клієнтський проєкт — Node.js API з Postgres, що не потребує бандлінгу авторизації чи сховища. Railway був правильним вибором, бо фаундер хотів простоту: один дашборд, один рахунок, жодних вендор-специфічних API.
Де дорожчає:
-
CPU-білінг. Railway бере за vCPU + пам'ять + сховище. Для Node.js API, що простоює більшу частину часу — дешево ($5–$10/міс). Для Postgres-інстансу, що робить аналітичні запити чи фонові задачі, CPU-споживання стрибає і рахунок разом із ним. У одного клієнта рахунок виріс із $12/міс до $47/міс після додавання нічної агрегації даних.
-
Немає serverless Postgres. Railway Postgres працює 24/7 на провізійованому інстансі. Ти платиш за аптайм, не за запити. Для застосунку з низьким трафіком, що отримує 100 запитів/день — ти платиш за базу, що простоює 99% часу. Serverless-модель Neon дешевша для цього сценарію.
-
Egress. Railway бере за egress після включеного об'єму. Якщо твій API роздає великі пейлоади (звіти, експорти, медіа) — вартість egress росте. Не проблема для більшості SaaS, але варто перевірити, якщо роздаєш файли.
Перевага: Нульовий lock-in. Railway не обгортає Postgres у пропрієтарний шар. Рядок підключення працює з будь-яким Postgres-клієнтом. Міграція — pg_dump і готово.
Цінові пороги Railway
| Сценарій | Місячна вартість | Нотатки |
|---|---|---|
| Хобі-проєкт, мінімальний трафік | $5 | Кредит Starter-плану покриває |
| API + Postgres, помірний трафік | $10–$25 | Просто і передбачувано |
| API + Postgres + фонові задачі | $30–$60 | Стрибки CPU від задач |
| Високий трафік, важкий compute | $80+ | Розглянь dedicated хостинг |
Neon: ставка на serverless
Neon — serverless Postgres. База масштабується до нуля в простої та піднімається на запит. Ти платиш за compute-години та зберігання, не за працюючий інстанс.
Де я використовував: Мій власний портфоліо-сайт (цей) і два клієнтські застосунки з низьким-до-помірного трафіком. Neon був правильним вибором, бо в цих застосунків стрибкоподібні патерни трафіку — тихо більшу частину дня, потім сплески в робочі години або під час заходів.
Де дорожчає:
-
Стійка конкурентність. Ціноутворення Neon дешеве, коли база простоює або обробляє спорадичні запити. Але якщо є постійний потік запитів (фонові воркери, real-time дашборди, високотрафікові API) — compute-години накопичуються швидко. Безкоштовний тариф дає 190 compute-годин/місяць. База, активна 8 годин/день, використовує ~240 compute-годин — ти на платному плані до кінця 1-го місяця.
-
Холодні старти. Коли база простоювала і приходить запит — є затримка холодного старту. Зазвичай 200–500ms для першого запиту. Для портфоліо-сайту ніхто не помічає. Для продакшн API, де P99 latency важлива — холодні старти о 3 ночі, коли перший користувач прокидається, реальна проблема. Можна тримати базу теплою cron-пінгом, але тоді ти платиш за compute-години, які не потрібні.
-
Гілкування неймовірне, масштабування складне. Кілер-фіча Neon — гілкування бази даних: створити копію продакшн-бази для тестування за секунди з copy-on-write, що мінімізує зберігання. Це реально трансформує девелоперський воркфлоу. Але модель автоскейлінгу робить рахунок менш передбачуваним, ніж фіксований інстанс. Для бюджетування я завжди додаю 30% буфер до передбачуваних витрат на Neon.
Перевага для serverless-застосунків: Якщо ти на Vercel із serverless-функціями, драйвер Neon @neondatabase/serverless використовує WebSocket-з'єднання замість TCP. Це прибирає головний біль connection pooling, що переслідує serverless Postgres. PgBouncer не потрібен. Кожен виклик функції отримує з'єднання, використовує його, скидає. Чисто.
Цінові пороги Neon
| Сценарій | Місячна вартість | Нотатки |
|---|---|---|
| Портфоліо/блог, низький трафік | $0 | Безкоштовний тариф щедрий |
| SaaS MVP, спорадичне використання | $0–$19 | Scale to zero економить |
| Зростаючий SaaS, помірний постійний трафік | $19–$69 | Pro-план, стеж за compute-годинами |
| Високий трафік, always-on навантаження | $69+ | Фіксований інстанс може бути дешевшим |
Коли що обирати
Обирай Supabase, коли:
- Потрібен auth + storage + Postgres пакетом
- Хочеш Row Level Security без написання свого middleware
- Команда маленька і all-in-one дашборд економить час
Обирай Railway, коли:
- Хочеш простий, передбачуваний хостинг
- Не потрібен auth або storage разом із базою
- Цінуєш нульовий lock-in і стандартний Postgres
- Запускаєш фонові задачі або воркери поряд із застосунком
Обирай Neon, коли:
- Застосунок serverless (Vercel, Cloudflare Workers)
- Трафік стрибкоподібний або низький (scale to zero економить)
- Хочеш гілкування бази для dev/test воркфлоу
- Комфортно з білінгом за споживанням
Мій дефолт для нових проєктів
Для клієнтських MVP, де фаундер хоче все в одному місці: Supabase Pro ($25/міс). Не найдешевший, але прибирає 3 рішення (провайдер авторизації, файлове сховище, хост бази), і дашборд достатньо хороший для нетехнічних фаундерів.
Для своїх проєктів і технічних клієнтів, що хочуть простоту: Neon Free → апгрейд до Pro, коли compute-години перевищують безкоштовний тариф. Serverless-модель ідеально підходить для Next.js на Vercel, а гілкування бази робить міграції схеми безболісними.
Для проєктів із фоновою обробкою або передбачуваним, стійким трафіком: Railway. Простий білінг, без сюрпризів, легко зрозуміти.
Збираєш щось і не впевнений, який хостинг-стек підходить? Напиши — порекомендую виходячи з реального патерну трафіку та бюджету, а не маркетингової сторінки.