Каждый новый 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 и хочешь второе мнение? Напиши — я помогаю фаундерам выбрать правильный стек, чтобы шипить правильное, а не просто модное.