Отличие 5: Схема (Schema)

Параметр	Реляционные (SQL)	Нереляционные (NoSQL)
Фиксация схемы	Схема определяется заранее (CREATE TABLE). Изменение схемы (ALTER TABLE) может быть сложным и долгим на больших таблицах.	Схема не фиксируется (schema-less). В одном документе может быть поле "email", в другом — нет.
Гибкость	Низкая. Все строки таблицы имеют одинаковый набор столбцов.	Высокая. Легко добавлять новые поля под разные объекты.

Отличие 6: Производительность

Параметр	Реляционные (SQL)	Нереляционные (NoSQL)
На чём оптимизированы	Универсальная нагрузка, транзакции, сложные запросы с JOIN'ами.	Специфические сценарии: очень быстрая запись, чтение по ключу, аналитика по колонкам, графовые обходы.
Скорость чтения	Высокая для простых запросов, падает при сложных JOIN'ах и больших таблицах.	Очень высокая для своего типа запросов (ключ-значение — микросекунды).
Скорость записи	Хорошая, но транзакции и индексы замедляют.	Очень высокая (особенно колоночные и in-memory key-value).

Характеристика	Реляционные (SQL)	Нереляционные (NoSQL)
Модель данных	Таблицы	Документы, ключ-значение, графы, колонки
Схема	Строгая, фиксированная	Гибкая, динамическая
Язык запросов	SQL (стандартизированный)	Специфичный для каждой БД
Транзакции	ACID (строгая согласованность)	BASE (согласованность в конечном счёте)
Масштабирование	Вертикальное (горизонтальное сложно)	Горизонтальное (распределённое)
Связи	Через внешние ключи и JOIN	Через вложенны документы или денормализацию
Когда использовать	Финансы, учёт, CRM, ERP — где критична целостность и сложная логика	Большие данные, реальное время, кэши, каталоги, соцсети

5. Сравнительная таблица

6. Когда что выбирать?

Выбираем реляционную БД (SQL), если:

• Данные строго структурированы и предсказуемы.

• Требуется строгая согласованность и поддержка транзакций ACID (финансовые операции, бронирования).

• Есть много сложных связей между сущностями, нужны JOIN'ы.

• Данные редко меняют структуру.

• Нужны сложные запросы и отчёты с агрегацией.

Выбираем нереляционную БД (NoSQL), если:

• Данные слабо структурированы или структура часто меняется.

• Требуется высокая скорость записи/чтения при огромных объёмах.

• Нужно горизонтальное масштабирование (кластер из множества серверов).

• Данные преимущественно самодостаточны (например, профили пользователей со всеми настройками).

• Вы работаете с конкретным типом данных: графы, временные ряды, огромные каталоги.

7. Тренд: NewSQL и мультимодельные базы

В последние годы появился класс NewSQL — системы, которые пытаются объединить лучшее из двух миров:

• ACID-транзакции и SQL как в реляционных.

• Горизонтальное масштабирование как в NoSQL.

Примеры: Google Spanner, CockroachDB, YugabyteDB.

Также набирают популярность мультимодельные базы, которые поддерживают несколько моделей данных в одной СУБД (например, можно работать и как с документной, и как с графовой, и как с реляционной). Пример: ArangoDB, OrientDB, PostgreSQL (с расширениями для JSON).