Кожен новий SaaS починається з одного питання: яка база даних? Раніше відповідь була «просто бери Postgres». У 2026 SQLite і DynamoDB закрили достатньо прогалин, щоб рішення варто було переглянути. Ось чесний розбір із проєктів, які я шипив на всіх трьох.
Дефолт: Postgres
Postgres — чесний дефолт для більшості SaaS-застосунків. Не тому що він найкращий у всьому — тому що він достатньо добрий у всьому і відмінний у тому, що найважливіше на ранній стадії SaaS.
Чому перемагає для більшості проєктів:
- Реляційні дані з гнучкими запитами. Дані SaaS реляційні. Користувачі належать організаціям, в організацій підписки, у підписок інвойси. Джойни, агрегації та складні запити працюють з коробки.
- Підтримка JSON, коли потрібна гнучкість схеми. Тип
jsonbу Postgres дає можливості документної БД, не покидаючи реляційну модель. Користувацькі налаштування, фіча-флаги, схеми форм — зберігай як JSON, запитуй через SQL. - Глибина екосистеми. Кожен ORM працює з Postgres. Кожна платформа хостингу підтримує його. Кожен інструмент моніторингу може підключитися. Ніколи не впрешся в стіну «не підтримується».
- Масштабування — проблема потім. Один інстанс Postgres обробляє більше трафіку, ніж побачить більшість SaaS на ранній стадії. Пулінг з'єднань (PgBouncer, пулер Supabase) піднімає цю стелю. Репліки читання піднімають ще. Думати про це не доведеться довго.
Де коштує грошей:
- Керований Postgres не безкоштовний. У Supabase, Railway та Neon є безкоштовні тіри, але реальне продакшн-використання починається з $10–25/міс.
- Керування з'єднаннями з серверлесом (Vercel, Cloudflare Workers) вимагає пулера. Без нього вичерпаєш з'єднання на піках трафіку.
- Селф-хостинг — значить ти відповідаєш за бекапи, апгрейди та фейловер. Не складно, але не безкоштовно.
Бери Postgres коли: будуєш багатокористувацький SaaS з реляційними даними, потрібні складні запити, або немає конкретної причини обрати щось інше.
Варіант «масштаб насамперед»: DynamoDB
DynamoDB — key-value/документна база від AWS. Горизонтально масштабується з нульовим операційним оверхедом. Ніколи не запускаєш ALTER TABLE, не керуєш з'єднаннями, не думаєш про дисковий простір.
Чому перемагає для певних проєктів:
- Передбачувана продуктивність на будь-якому масштабі. Читання за одиниці мілісекунд незалежно від розміру таблиці. Для тікетінгової платформи, що обробляє тисячі одночасних бронювань місць — це важливо.
- Нульовий операційний оверхед. Жодних інстансів для керування, з'єднань для пулінгу, вакуумування. Платиш за запит або провіжн ємність — AWS робить решту.
- Event-driven патерни. DynamoDB Streams тригерять Lambda-функції на кожен запис. Для event sourcing, аудит-логів або real-time синхронізації — це вбудовано, а не прикручено.
Де коштує грошей:
- Патерни доступу потрібно проєктувати заздалегідь. Не можна просто «виконати запит». Кожен патерн доступу вимагає попередньо спроєктованого індексу. Зміниш патерни запитів через 6 місяців? Можливо, доведеться перебудувати таблицю.
- Немає джойнів. Якщо дані реляційні — або денормалізуєш (дублювання даних), або робиш кілька запитів (латенсі). Для SaaS з користувачами, командами, білінгом і правами — швидко стає болісно.
- Вендор лок-ін. DynamoDB — тільки AWS. Локальна розробка — DynamoDB Local (Java Docker-контейнер, який приблизно відповідає продакшну). Міграція — переписування шару даних.
- Несподівані витрати. Ціноутворення за запитом просте, поки бот не вдарить по API 10М разів. Провіжн ємності дешевший, але вимагає прогнозування.
Бери DynamoDB коли: у тебе single-table дизайн з передбачуваними патернами доступу, ти вже на AWS, і горизонтальне масштабування — вимога з першого дня (високопропускний IoT, ігрові лідерборди, real-time прийом подій).
Андердог: SQLite
SQLite — вбудована база даних, що працює в тому ж процесі, що й застосунок, читаючи та записуючи один файл на диску. Звучить як іграшка. У 2026 це легітимний продакшн-вибір для дивовижного діапазону SaaS-застосунків.
Чому раптом актуальний:
- Нульова латенсі. Жодних мережевих раунд-тріпів. Запити виконуються в мікросекундах, не мілісекундах. Для read-heavy застосунків нічого швидшого немає.
- Нульові операційні витрати. Жодних серверів БД, рядків підключення, пулінгу, бекапів за розкладом. База — це файл. Бекап — копіювання файлу.
- Litestream/LiteFS для реплікації. Litestream стримить WAL-зміни в S3 у реальному часі. LiteFS (від Fly.io) надає репліки читання по регіонах. Ці інструменти зробили SQLite життєздатним для розподілених деплоїв.
- Turso та libSQL. Turso — керований SQLite з мультирегіональною реплікацією та HTTP API. libSQL додає фічі на кшталт нативного векторного пошуку. В екосистеми реальний моментум.
Де коштує грошей:
- Обмеження одного писця. SQLite обробляє один запис за раз. Для write-heavy навантажень (чат-повідомлення, real-time колаборація) впрешся в цю стелю. WAL-режим допомагає, але не усуває.
- Немає вбудованої реплікації. Без Litestream або LiteFS — один файл на одному сервері. Сервер помер — дані померли (якщо не забекапив).
- Обмежені паралельні з'єднання. У SQLite немає клієнт-серверної моделі. Якщо 50 конкурентних воркерів б'ють по базі — контенція стає проблемою.
Бери SQLite коли: будуєш read-heavy застосунок, персональний SaaS з низькою конкурентністю запису, edge-deployed застосунок (одна база на регіон), або хочеш максимально просту операційну історію.
Таблиця рішень
| Фактор | Postgres | DynamoDB | SQLite |
|---|---|---|---|
| Модель даних | Реляційна + JSON | Key-value / документ | Реляційна |
| Гнучкість запитів | Повний SQL | Попередньо спроєктовані патерни | Повний SQL |
| Стеля масштабування | Висока (з пулінгом + репліками) | Фактично безлімітна | Середня (один писець) |
| Операційний оверхед | Середній | Нульовий | Нульовий |
| Вартість при малому трафіку | $10–25/міс | Майже нуль (за запитом) | $0 |
| Вартість при великому трафіку | Передбачувана | Змінна (стеж за on-demand) | Майже нуль |
| Локальна розробка | Нативна | DynamoDB Local (неідеальний) | Нативна |
| Гнучкість міграції | Висока (стандартний SQL) | Низька (тільки AWS) | Висока (стандартний SQL) |
Мій дефолт
Для SaaS-проєктів, які я шиплю клієнтам, дефолт — Postgres на Supabase або Neon. Він обробляє реляційні дані природно, масштабується далеко за перші кілька тисяч користувачів, має відмінний тулінг і не прив'язує до вендора.
За DynamoDB берусь тільки коли проєкт вже на AWS і патерни доступу дійсно прості та високопропускні.
За SQLite берусь коли модель деплою того вимагає — edge-first застосунки, single-tenant сетапи, або коли операційна простота переважує обмеження конкурентності запису.
«Чесний дефолт» у заголовку — Postgres. Не тому що він завжди найкращий — тому що це вибір, про який ти пошкодуєш найменше, коли вимоги зміняться на 6-му місяці.
Обираєш базу даних для SaaS і хочеш друге мнення? Напиши — я допомагаю фаундерам обрати правильний стек, щоб шипити правильне, а не просто модне.