PostgreSQL, MySQL, SQLite, MongoDB и Redis: чем отличаются базы данных

Заказ в интернет-магазине нельзя потерять. Сессию пользователя хочется быстро найти и автоматически удалить через полчаса. А для годового отчёта приходится читать миллионы событий. Всё это данные, но работа с ними устроена по-разному.

Поэтому существует не одна «лучшая база», а много систем с разными компромиссами. PostgreSQL и MySQL хорошо управляют связанными таблицами и транзакциями, SQLite хранит локальную базу в одном файле, MongoDB работает с документами, Redis — со структурами данных в памяти, ClickHouse — с аналитическими запросами по большим массивам событий.

Разберём, чем отличаются популярные СУБД, насколько у них разный синтаксис и как выбрать подходящую без коллекции из пяти серверов на старте проекта.

База данных и СУБД — не одно и то же

База данных — организованный набор данных. Система управления базами данных, или СУБД, — программа, которая хранит этот набор, выполняет запросы, следит за правами доступа и восстанавливает данные после сбоев.

PostgreSQL, MySQL и MongoDB — названия СУБД. База магазина shop внутри PostgreSQL — конкретная база данных. В разговоре обе вещи часто называют просто «базой», но при сравнении технологий речь обычно идёт именно о СУБД.

Главное различие — модель данных и тип нагрузки

Название «NoSQL» создаёт ложное ощущение, будто все базы можно разделить на SQL и NoSQL. Полезнее смотреть на то, как система представляет данные и какие операции считает основными.

В реляционной базе данные лежат в таблицах, а связи задаются ключами и ограничениями. Например, заказ ссылается на клиента, но имя клиента не копируется в каждую строку заказа. Такой подход помогает не допустить заказа без существующего клиента и обновлять один факт в одном месте. Подробнее этот принцип разобран в статье про нормализацию.

В документной базе заказ может храниться одним вложенным документом вместе с адресом и позициями. Документация MongoDB рекомендует встраивать данные, которые часто читаются вместе: это сокращает число отдельных обращений, но иногда приводит к дублированию.

Redis идёт ещё дальше: вместо таблиц он предлагает строки, хеши, списки, множества, упорядоченные множества и потоки. Эти типы заточены под конкретные операции — например, счётчик, очередь или рейтинг. Полный набор описан в официальном справочнике Redis.

ClickHouse хранит значения одного столбца рядом и читает только нужные для запроса столбцы. Поэтому колоночная модель подходит для агрегаций по большому числу событий, тогда как построчные PostgreSQL и MySQL удобнее для чтения и изменения отдельных записей. Разницу между этими нагрузками объясняет документация ClickHouse.

SQL похож между СУБД, но это не один язык до последнего символа

PostgreSQL, MySQL, SQLite и SQL Server понимают общую основу SQL: SELECT, INSERT, UPDATE, DELETE, WHERE, JOIN, GROUP BY и ORDER BY. Такой запрос почти не меняется между ними:

SELECT customer_id, sum(total) AS revenue
FROM orders
WHERE status = 'paid'
GROUP BY customer_id
ORDER BY revenue DESC;

Именно поэтому знания о фильтрации, соединениях, группировке и NULL переносятся из одной реляционной СУБД в другую. Но у каждой реализации свой диалект: расширения стандарта, функции, типы данных и правила для спорных случаев.

Один запрос в двух диалектах

SELECT id, created_at
FROM orders
ORDER BY created_at DESC
LIMIT 10;

SELECT TOP (10) id, created_at
FROM orders
ORDER BY created_at DESC;

Без ORDER BY обе формы означают «верни любые десять подходящих строк», а не первые или последние по смыслу приложения. PostgreSQL описывает LIMIT в справочнике по запросам, а Microsoft рекомендует сочетать TOP с ORDER BY для предсказуемого результата в документации T-SQL.

С идентификаторами разница глубже названий. У SQLite INTEGER PRIMARY KEY связан со встроенным ROWID, а AUTOINCREMENT обычно не требуется: он запрещает повторное использование старых значений, но добавляет накладные расходы. Это поведение отдельно объяснено в документации SQLite.

Upsert тоже не переносится посимвольно. PostgreSQL называет ON CONFLICT своим расширением SQL, MySQL документирует конструкцию ON DUPLICATE KEY UPDATE, а в T-SQL есть MERGE. Меняются ссылки на новую строку, выбор конфликтующего ограничения и детали конкурентного выполнения.

Различия продолжаются в типах, функциях, датах, JSON, регистре текста и кавычках вокруг имён. Булево значение может быть типом boolean, синонимом маленького целого или типом bit.

ORM скрывает часть этих отличий, но не отменяет их. Миграции, индексы, полнотекстовый поиск, блокировки и сложные запросы всё равно приходится проверять на той СУБД и той версии, где работает приложение. Даже сообщения о синтаксической ошибке выглядят по-разному — сравнение PostgreSQL и MySQL есть в отдельном разборе.

У MongoDB и Redis уже другой интерфейс запросов

У нереляционных систем меняется не только диалект, но и сам способ обращения к данным.

db.orders
  .find({ status: 'paid' })
  .sort({ createdAt: -1 })
  .limit(10)

SET session:42
  '{"userId":7}'
  EX 1800

ClickHouse, напротив, использует SQL, но его диалект, функции, движки таблиц и модель обновлений отличаются от PostgreSQL или MySQL. Знакомый SELECT облегчает старт, но не делает системы взаимозаменяемыми.

Что решает каждая популярная СУБД

Ниже не рейтинг, а карта сценариев. Одна система может закрывать несколько задач, но у каждой есть область, где её устройство особенно полезно.

Почему одна СУБД не умеет всё одинаково хорошо

Требования к хранению конфликтуют на уровне устройства системы:

• Строки ↔ столбцы Отдельную запись быстрее обрабатывать построчно, большой аналитический срез — по столбцам.
• Память ↔ диск Память убирает чтение с диска, но меняет бюджет и стратегию сохранности.
• Связи ↔ документы Нормализация сокращает дублирование, встраивание сокращает число отдельных чтений.
• Файл ↔ сервер Локальный файл не требует администрирования, сервер координирует множество клиентов.
• Гарантии ↔ координация Строгие гарантии между узлами требуют согласования, которое влияет на задержку и поведение при сбоях сети.

Есть и нетехнические причины: совместимость со старым кодом, привычки команды, облачные сервисы, лицензии, инструменты резервного копирования и мониторинга. СУБД живёт внутри экосистемы, поэтому две системы с похожими функциями всё равно могут быть рациональным выбором для разных компаний.

Как выбрать базу данных для проекта

Начни не со списка функций, а с данных и запросов:

1. Что нельзя потерять? Для заказов, платежей и прав доступа сначала рассматривай реляционную СУБД с транзакциями и ограничениями.
2. Какие связи есть между сущностями? Если запросы постоянно соединяют пользователей, заказы и товары, PostgreSQL или MySQL обычно проще документной модели.
3. Где живут данные? Для локального файла внутри приложения проверь SQLite до развёртывания отдельного сервера.
4. Есть ли измеренная специальная нагрузка? Кеш с TTL и счётчиками указывает на Redis, аналитика по большому потоку событий — на ClickHouse.
5. Что уже умеет команда? Знакомая СУБД с резервными копиями и мониторингом часто безопаснее более модного продукта без эксплуатации.

Большинству новых серверных приложений на старте хватает одной реляционной базы — PostgreSQL или MySQL. PostgreSQL умеет хранить JSON, SQLite справляется с локальными данными, а индекс часто решает проблему раньше дополнительной СУБД.

Добавляй MongoDB, Redis или ClickHouse, когда появилась конкретная нагрузка и замеры показали предел текущего решения. Иначе вместе со второй базой придут синхронизация, резервные копии, мониторинг, права доступа и ещё один сценарий аварии.

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

Короткий ответ

Популярных баз данных много, потому что они оптимизируют разные операции. PostgreSQL, MySQL и SQL Server — универсальные реляционные серверы; SQLite — встраиваемая реляционная база; MongoDB хранит документы; Redis предоставляет структуры данных в памяти; ClickHouse обрабатывает аналитические запросы по столбцам.

SQL между реляционными СУБД похож в основе, но различается в ограничении строк, генерации идентификаторов, upsert, типах, функциях и DDL. Учить стоит общие принципы, а синтаксис сверять с документацией конкретной версии.