SQL (реляционная модель)
Сильные стороны (PostgreSQL, MySQL):
- строгая схема, ACID;
- joins и аналитические запросы;
- зрелые индексы (B-tree, GIN, BRIN), MVCC, WAL, PITR.
Слабые стороны: вертикальное масштабирование, дорогой sharding (Citus, Vitess), миграции схемы под нагрузкой.
NoSQL
Документные (MongoDB), key-value (Redis, DynamoDB), wide-column (Cassandra), graph (Neo4j). Общие свойства:
- гибкая схема (документ/ключ);
- горизонтальное масштабирование через sharding из коробки;
- транзакционные гарантии зависят от конкретной системы: MongoDB поддерживает multi-document ACID с 4.0/4.2, DynamoDB — транзакционные операции, Cassandra обычно проектируют вокруг денормализации и idempotent writes.
Как выбирать
- транзакционная целостность между сущностями обязательна → SQL;
- доминируют point lookups по ключу → key-value;
- доменная модель агрегирована и часто меняется → document;
- большие объёмы insert-heavy и аналитика → wide-column / OLAP;
- сложные графовые запросы → graph.
Сравнить: latency p95/p99 на реальном профиле, поведение при failover, операционная стоимость (backup, observability, миграции).
Анти-паттерны
- выбор «по тренду»;
- перенос OLTP-схемы 1:1 в документную БД;
- игнорирование day-2 (backup, alerts, failover drills);
- использование NoSQL «потому что быстрее» без замеров.
Practical checklist
- Транзакции: обязательны или локальны для одного агрегата?
- Профиль чтения/записи: пиковая нагрузка, ratio, паттерны?
- Эволюция схемы: частота миграций, downtime бюджет?
- SLO: latency, availability, durability (RPO/RTO)?
- Операции: backup, мониторинг, expertise команды?
Часто оптимум — гибрид: PostgreSQL для core-транзакций, Redis для кэша/очередей, OLAP-движок для аналитики.