←Все статьи

SQL vs NoSQL в 2026: когда реляционная база всё ещё лучший выбор

Базы данных5 мин чтения
  • #sql
  • #nosql
  • #postgresql
  • #mongodb
  • #newsql

«NoSQL убил реляционные базы» — слоган 2012 года, который не подтвердился. В 2026 году SQL по-прежнему доминирует, а NoSQL занял конкретные ниши, а не заменил реляционные базы повсеместно. Дискуссия сместилась: вопрос не «SQL или NoSQL», а «под какой характер данных и запросов — какое хранилище». Разберём по типам хранилищ и их реальным кейсам.

Реляционные SQL-базы

PostgreSQL, MySQL, MS SQL Server, Oracle. Таблицы со строгой схемой, SQL как язык запросов, ACID-транзакции, JOIN-ы, внешние ключи.

Сильные стороны. Гарантии целостности данных (ACID), декларативный язык запросов (SQL), богатая экосистема инструментов и навыков, хорошо изученная модель. Если данные предметной области естественно ложатся в связанные таблицы, а запросы требуют JOIN, агрегаций и транзакционной целостности — SQL до сих пор лучший выбор.

Слабые стороны. Схема жёсткая: любое изменение структуры — миграция. Масштабирование по горизонтали (на несколько серверов) сложное, исторически реляционные базы масштабируют вертикально (более мощный сервер). Тяжёлые модели в JSON-подобных документах работают неуклюже.

По-прежнему дефолт для большинства приложений. Стартуйте с PostgreSQL — закроете 90% задач.

Ключ-значение (key-value)

Redis, DynamoDB, Memcached. Хранилище по принципу словаря: ключ → значение. Никаких связей, JOIN-ов, сложных запросов по значению.

Кейсы. Кеш (Redis под тяжёлые запросы к БД), сессии пользователей, счётчики, очереди задач, распределённые блокировки. Там, где важна скорость (миллисекунды), а не богатые запросы.

Сильные стороны. Очень быстро (данные в памяти, у Redis), предсказуемая задержка, простая модель.

Слабые стороны. Не подходит как основное хранилище с богатой предметной моделью — нет ни JOIN, ни сложных запросов. Данные должны помещаться в RAM (для in-memory вариантов), что ограничивает объём.

Документные базы

MongoDB, Couchbase, Amazon DocumentDB. Хранят документы (обычно JSON/BSON) целиком, без обязательной схемы.

Кейсы. CMS, каталоги товаров с переменной структурой, профили пользователей с разными полями, иерархические данные.

Сильные стороны. Гибкая схема — каждый документ может иметь свои поля, без миграций. Естественное соответствие объектам в коде (особенно в JavaScript-стеке). Хорошо для прототипирования.

Слабые стороны. На сложных запросах с JOIN по нескольким коллекциям начинают буксовать (фактически — эмуляция JOIN в коде, что дорого). Транзакции по нескольким документам появились (в MongoDB с 4.0), но они медленнее, чем в реляционных базах, и применять их ко всей предметной области неудобно. Многие команды, начав на MongoDB, со временем возвращаются к PostgreSQL — потому что реляционные базы научились хранить JSON (см. ниже), а документные базы так и не научились делать JOIN так же хорошо.

Колоночные / Wide-column

ClickHouse, Apache Cassandra, HBase, ScyllaDB. Хранят данные по колонкам, а не по строкам; оптимизированы под аналитику на больших объёмах.

Кейсы. Логи и метрики (миллиарды событий), аналитика (OLAP), временные ряды (time series). ClickHouse — стандарт для аналитики на терабайтах.

Сильные стороны. Фантастическая скорость агрегаций на больших данных, компрессия (похожие значения рядом — хорошо сжимаются), горизонтальное масштабирование.

Слабые стороны. Плохо подходят для транзакционных нагрузок (OLTP), точечных обновлений одиночных строк, сложных ACID-транзакций. Не замена основной базе приложения.

Графовые базы

Neo4j, Amazon Neptune, ArangoDB (мультимодельная). Хранят данные как узлы и рёбра; язык запросов заточен под обход связей.

Кейсы. Социальные связи, рекомендации, фрод-детекшн, анализ путей — задачи, где «найти всех друзей друзей пользователя, которые лайкнули этот товар» — естественный запрос.

Сильные стороны. Запросы по связям, которые в SQL превратились бы в 5–6 уровней JOIN, выполняются естественно и быстро.

Слабые стороны. Узкая ниша. Для типового CRUD-приложения избыточны.

Два развития, которые сняли часть холиваров

JSONB в PostgreSQL

Реляционная база научилась хранить и индексировать JSON. Колонка типа JSONB хранит JSON-документ, по которому можно делать запросы (WHERE data->>'type' = 'article') и строить GIN-индексы. Большинство «нам нужен MongoDB»-кейсов закрываются одним PostgreSQL: жёсткая схема для основных данных, гибкий JSONB для переменной части. Не нужно тащить вторую базу.

-- Таблица с фиксированными полями + гибким JSON для метаданных
CREATE TABLE products (
  id serial PRIMARY KEY,
  name text NOT NULL,
  attributes jsonb
);
CREATE INDEX ON products USING gin (attributes);
-- Найти все товары с определённым атрибутом
SELECT * FROM products WHERE attributes @> '{"color": "red"}';

NewSQL

CockroachDB, Google Spanner, YugabyteDB. Горизонтально масштабируемые базы с ACID-гарантиями и SQL-диалектом. Снимают главную боль классических реляционных баз (вертикальное масштабирование), сохраняя SQL и транзакции. Используются в высоконагруженных распределённых системах. Для большинства приложений избыточны — но когда Postgres-инстанс упирается в железо и шардинг в приложении становится болью, NewSQL — реальная альтернатива.

Правило выбора

Не выбирайте базу под моду или под «масштабируемость, которая когда-нибудь понадобится». Выбирайте под характер данных и запросов:

  1. Какова предметная модель? Связанные сущности с целостностью → SQL. Переменная структура документов → JSONB в SQL или документная БД. События/логи → колоночная.
  2. Какие запросы? Сложные аналитические JOIN на терабайтах → ClickHouse. Простое «дай по ключу» → Redis. Графовые связи → Neo4j. Всё остальное → SQL.
  3. Какие гарантии нужны? Строгие ACID-транзакции → SQL. Допустима eventual consistency → больше вариантов.

И главное: начинайте с PostgreSQL, пока нет измеримой потребности в другом. Это закроет 90% задач, и переход на специализированную базу (Redis для кеша, ClickHouse для аналитики) делается точечно под конкретную боль, а не «на будущее».

Короткое summary

SQL не убит NoSQL, а NoSQL не заменил SQL — они заняли разные ниши. Реляционные базы (PostgreSQL) по-прежнему дефолт для большинства приложений с ACID-гарантиями и связанными данными. Ключ-значение (Redis) — для кеша и сессий, документные (MongoDB) — для переменных структур, колоночные (ClickHouse) — для аналитики на больших данных, графовые (Neo4j) — для задач по связям. JSONB в PostgreSQL снял много «NoSQL»-кейсов, а NewSQL (CockroachDB, Spanner) убрал главную боль реляционных баз — вертикальное масштабирование. Выбор — по характеру данных и запросов, не по моде, и начать стоит с PostgreSQL.

Что почитать