SQL и NoSQL в 2026: как выбрать базу данных для современного приложения

11 мин. чтения

SQL и NoSQL в 2026: как выбрать базу данных для современного приложения

Введение

Выбор базы данных — одно из первых архитектурных решений, которое принимает команда при старте проекта. И одно из самых сложных для пересмотра. В 2026 году ландшафт баз данных радикально отличается от того, что был десять лет назад: SQL не умер, NoSQL не заменил реляционные базы, а на сцену вышла третья сила — Distributed SQL. Согласно опросу Stack Overflow 2024 года, PostgreSQL использует 48,7% разработчиков, MongoDB — 25,3%. При этом 68% разработчиков работают с SQL, 35% — с NoSQL, а значительная часть использует оба подхода в рамках одной архитектуры (polyglot persistence).

В этой статье мы разберём актуальное состояние SQL и NoSQL баз данных в 2026 году, рассмотрим ключевые тренды (PostgreSQL 18 с async I/O, MongoDB 8.0, Distributed SQL), сравним производительность на основе независимых бенчмарков и дадим практический framework для выбора. Материал основан на данных CNCF, DORA, независимых бенчмарков Microsoft, AWS и Percona, а также на production-кейсах компаний Netflix, Uber, Discord и OpenAI.

SQL в 2026: реляционные базы не сдаются

Реляционные базы данных — это «рабочая лошадка» индустрии уже более сорока лет. В 2026 году они не только не устарели, но и получили значительные улучшения. PostgreSQL 18, выпущенная в сентябре 2025 года, стала самым значительным релизом за последние годы, а PostgreSQL 19 Beta (июнь 2026) продолжает расширять возможности.

PostgreSQL 18: революция async I/O

Главное нововведение PostgreSQL 18 — асинхронная подсистема ввода-вывода (AIO), работа над которой велась с 2019 года. Ранее PostgreSQL работал по синхронной модели: каждый запрос на чтение был блокирующим системным вызовом. База данных запрашивала один 8-килобайтный блок у операционной системы, ждала его доставки, обрабатывала, и только затем запрашивала следующий.

Асинхронный I/O меняет эту модель кардинально. PostgreSQL 18 может отправлять несколько запросов на чтение одновременно, не дожидаясь завершения каждого. Это особенно эффективно для sequential scan, bitmap heap scan и операций VACUUM. Независимые бенчмарки показывают впечатляющие результаты:

|---|---|---|---|

| Sequential scan, 40 ГБ (холодные данные) | 52 с | 18 с | ×2,9 |

| pgbench read-heavy TPS | 24 100 | 35 700 | +48% |

| Index scan | 1x | до 2,1x | ×2,1 |

Как это работает? PostgreSQL 18 использует механизм io_uring в Linux, который позволяет отправлять пакеты I/O-запросов через единое кольцо (ring) в пространстве ядра, без системных вызовов на каждую операцию. База данных планирует, какие блоки понадобятся в ближайшее время (на основе плана выполнения запроса), и запрашивает их заранее, параллельно обрабатывая уже полученные данные.

Другие значимые улучшения PostgreSQL 18:

UUIDv7 — нативная функция uuidv7(), генерирующая монотонно возрастающие UUID, которые не страдают от фрагментации индексов в отличие от UUIDv4.
Skip Scan — оптимизация для много-колоночных B-tree индексов: теперь запросы с условиями, не затрагивающими префиксные колонки, могут эффективно использовать индекс.
OAuth 2.0 — нативная поддержка единого входа (SSO) для аутентификации.
Виртуальные генерируемые колонки — значения вычисляются на лету, не занимая место на диске.
Сохранение статистики при обновлении версии — pg_upgrade теперь переносит планировщик статистики, устраняя проблему деградации производительности после мажорного обновления.
Ускорение внешних ключей — проверка ограничений внешнего ключа стала в 2 раза быстрее (PostgreSQL 19).

ACID как конкурентное преимущество

Главный технический аргумент в пользу SQL — ACID-транзакции. Atomicity, Consistency, Isolation, Durability — гарантии, которые никуда не делись и остаются критическими для финансовых систем, e-commerce, бронирований и любого приложения, где целостность данных важнее скорости.

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

NoSQL в 2026: эволюция, а не стагнация

NoSQL-базы данных прошли большой путь с момента появления MongoDB в 2009 году. В 2026 году NoSQL — это не единая категория, а четыре разных типа: document stores (MongoDB, Couchbase), key-value stores (Redis, DynamoDB), wide-column stores (Cassandra, ScyllaDB) и graph databases (Neo4j, Dgraph).

MongoDB 8.0: 36% быстрее и векторный поиск

MongoDB 8.0, выпущенная в 2025 году, — самый значительный релиз компании. По данным официальных бенчмарков, MongoDB 8.0 на 36% быстрее на чтении и на 32% быстрее на смешанной нагрузке по сравнению с MongoDB 7.0. Независимые тесты Percona подтверждают 12% улучшения на однопоточном сценарии и до 20–30% на отдельных операциях.

Ключевые улучшения MongoDB 8.0:

Ускорение записи до 54% на write-heavy сценариях (YCSB Write Bulk Data).
Ускорение Time Series нагрузок до 60% благодаря оптимизированному columnar storage.
Векторный поиск — первоклассная поддержка Approximate Nearest Neighbor (ANN) поиска для AI/ML-приложений. MongoDB Atlas Vector Search интегрируется с Hugging Face, LangChain и LlamaIndex.
Улучшенное шардирование — автоматический rebalancing с minimial downtime.
Encrypted Query — выполнение запросов над зашифрованными данными без расшифровки на сервере.

Важный контекст: MongoDB 7.0, с которой сравнивается 8.0, имела серьёзные проблемы с производительностью — многие пользователи сообщали о деградации по сравнению с 6.0. Поэтому цифры в 36% нужно рассматривать в этом контексте. При миграции с 6.0 на 8.0 прирост будет скромнее, но всё равно значимым.

Четыре типа NoSQL: когда что использовать

Document stores (MongoDB, Couchbase). JSON-подобные документы, гибкая схема. Идеально для каталогов продуктов, контент-менеджмента, пользовательских профилей. Оценка флага — чистая функция без сетевого вызова, типичное время — менее 1 миллисекунды.

Key-value stores (Redis, DynamoDB). Максимальная производительность для простых операций get/set. Используются для кэширования, сессий, очередей. Redis остаётся стандартом для in-memory кэша, DynamoDB доминирует в serverless-экосистеме AWS.

Wide-column stores (Cassandra, ScyllaDB). Оптимизированы для записей и горизонтального масштабирования. Выбор для time-series данных, IoT, логов. ScyllaDB, написанная на C++, показывает до 5× большую пропускную способность на узел по сравнению с Cassandra.

Graph databases (Neo4j, Dgraph). Для данных с богатыми связями: социальные графы, рекомендательные системы, обнаружение мошенничества. В 2026 году graph databases активно используются в AI-пайплайнах для RAG (Retrieval-Augmented Generation).

Distributed SQL: третья сила

Пожалуй, самый интересный тренд 2026 года — Distributed SQL (ранее известный как NewSQL). Эти системы пытаются объединить лучшее из двух миров: SQL-интерфейс и ACID-транзакции реляционных баз с горизонтальной масштабируемостью NoSQL.

Как это работает

Distributed SQL использует разделяемый-nothing (shared-nothing) архитектуру с консенсус-протоколом Raft. Данные автоматически партицируются (шардируются) по узлам кластера, и каждое изменение проходит через подтверждение большинства реплик (кворум). Это обеспечивает сильную согласованность (strong consistency) без единой точки отказа.

Игроки рынка

CockroachDB — наиболее зрелая Open Source distributed SQL (Graduated CNCF). Полная совместимость с PostgreSQL wire protocol, Serializable изоляция по умолчанию. Лучший выбор для multi-region деплоя.

YugabyteDB — PostgreSQL-совместимая distributed SQL, использующая DocDB (LSM-tree) как storage engine. Преимущество — до 5× более высокая пропускная способность записи для PostgreSQL workload благодаря LSM-дереву.

Google Spanner — проприетарная distributed SQL от Google. Использует TrueTime (синхронизированные атомные часы) вместо Raft-консенсуса для более эффективной координации транзакций. Доступен как Cloud Spanner.

TiDB — HTAP-ориентированная distributed SQL с отдельным columnar storage (TiFlash) для аналитических запросов.

Когда выбирать Distributed SQL

Distributed SQL оправдан, когда:

Приложение требует глобальной мульти-региональной отказоустойчивости
Write throughput превышает возможности single-node PostgreSQL (обычно >50 000 writes/s)
Нужны ACID-транзакции с горизонтальным масштабированием
Команда не хочет заниматься ручным шардированием

Для большинства стартапов и средних проектов Distributed SQL избыточен. Переплата за консенсус (20–50% дополнительной задержки на запись) не оправдана, если приложение работает в одном регионе и не требует multi-region availability.

Polyglot Persistence: норма, а не исключение

В 2026 году подавляющее большинство production-систем используют несколько баз данных. Это не «архитектурная сложность» — это прагматичный подход, когда каждая база данных используется для своей задачи.

Типичная конфигурация:

PostgreSQL — основное хранилище с данными, требующими ACID (заказы, пользователи, транзакции).
MongoDB — каталог продуктов, контент, гибкие схемы данных.
Redis — кэш, сессии, очереди, rate limiting.
Elasticsearch — полнотекстовый поиск.
Neo4j — графовые запросы для рекомендаций.
ScyllaDB/Cassandra — time-series данные, логи, метрики.

Согласно отчёту CNCF за Q1 2026, использование полиглотной персистентности выросло на 40% по сравнению с 2023 годом. Инструменты observability (Datadog, New Relic, Grafana) поддерживают все типы баз данных, что снижает операционную сложность.

Decision Framework: как выбрать

Ниже — практическая система оценки. По каждому критерию оцените важность от 1 (не важно) до 3 (критично).

|---|---|---|---|

| ACID-транзакции обязательны | ✓ | | ✓ |

| Гибкая схема данных | | ✓ | |

| Горизонтальное масштабирование | (через шардирование) | ✓ | ✓ |

| Multi-region отказоустойчивость | | | ✓ |

| Сложные JOIN / аналитика | ✓ | | ✓ |

| Высокая скорость записи | | ✓ | |

| Низкая задержка (единицы мс) | ✓ | ✓ | (выше) |

| Команда знает SQL | ✓ | | ✓ |

Правило большого пальца:

Если вам нужны ACID-транзакции и вы не планируете >50 000 writes/s — выбирайте PostgreSQL. Это правильный выбор для 80% проектов.
Если у вас гибкие документы, каталоги, пользовательские профили — MongoDB.
Если вам нужен кэш — Redis.
Если вам нужно глобальное мульти-региональное приложение с ACID — CockroachDB или YugabyteDB.
Если вам нужна максимальная скорость записи для time-series — ScyllaDB.
Если вам нужен полнотекстовый поиск — Elasticsearch.

Реальные кейсы

Netflix. Использует комбинацию PostgreSQL (учётные данные, подписки), Cassandra (time-series, история просмотров), Elasticsearch (поиск), Redis (кэш, сессии). Публичный API остаётся на REST, но внутренние сервисы активно используют gRPC и event-driven взаимодействие через Kafka.

Uber. Мигрировал основное хранилище с PostgreSQL (с кастомным шардированием под названием Schemaless) на собственный Distributed SQL — DocStore. Использует Cassandra для time-series и Redis для кэширования геоданных.

Discord. Использует PostgreSQL для основных данных (пользователи, сообщения, серверы) с ScyllaDB для сообщений в реальном времени. Discord обрабатывает миллионы сообщений в секунду, и ScyllaDB обеспечивает предсказуемую задержку при записи.

OpenAI. Использует PostgreSQL для метаданных (пользователи, подписки, billing), Pinecone/Weaviate для векторного поиска (embeddings), Redis для rate limiting и кэширования промптов. MongoDB используется для хранения логов взаимодействий с моделями.

Заключение

Выбор базы данных в 2026 году — это не бинарный выбор между SQL и NoSQL. Это вопрос правильной комбинации для вашего конкретного сценария. PostgreSQL остаётся универсальным выбором для большинства проектов, особенно с выходом версии 18, которая устранила главное узкое место — синхронный I/O. MongoDB 8.0 значительно улучшила производительность и добавила критический функционал для AI-эры (векторный поиск). Distributed SQL (CockroachDB, YugabyteDB) открывает новые возможности для глобальных приложений.

Ключевой совет: начинайте с PostgreSQL. Он покроет 80% ваших потребностей. Добавляйте NoSQL, когда появится конкретная причина: документо-ориентированные данные (MongoDB), кэширование (Redis), time-series (ScyllaDB), графы (Neo4j). Distributed SQL рассматривайте только тогда, когда single-node PostgreSQL перестанет справляться с write throughput или когда потребуется multi-region отказоустойчивость.

Polyglot persistence — это не архитектурная роскошь, а инженерная необходимость. Вопрос не в том, использовать ли несколько баз данных, а в том, как правильно их комбинировать, не создавая операционного хаоса.

FAQ

Нужен ли мне Distributed SQL, если мы используем PostgreSQL с read replicas?

Нет. Read replicas решают проблему read scaling. Distributed SQL решает проблему write scaling и multi-region отказоустойчивости. Если ваш write throughput укладывается в возможности одного primary (обычно >50 000 writes/s) и вы работаете в одном регионе — PostgreSQL с репликами достаточен.

PostgreSQL 18 настолько быстрее 17, что стоит немедленно обновляться?

Async I/O даёт впечатляющий прирост на sequential scan и VACUUM — до 3×. Для OLTP-нагрузок с маленькими запросами, попадающими в кэш, разница будет менее заметна. Обновляться стоит, но с тестированием: расширения pgvector, TimescaleDB, PostGIS требуют проверки совместимости.

MongoDB по-прежнему теряет данные при записи?

Это один из самых живучих мифов. MongoDB 8.0 с включённым journaling (по умолчанию) имеет durability на уровне ACID-совместимых баз. Проблемы с потерями данных были в версиях до 3.0 (2015 год). С версии 5.0 MongoDB поддерживает multi-document ACID-транзакции.

Что выбрать для нового стартапа в 2026 году?

PostgreSQL. Это самый безопасный выбор: огромное комьюнити, зрелый инструментарий, отличная производительность, JSONB для гибких схем, отличная расширяемость (pgvector, PostGIS, TimescaleDB). Добавляйте другие базы данных по мере появления конкретных потребностей.

В чём преимущество NoSQL, если PostgreSQL теперь поддерживает JSONB?

JSONB в PostgreSQL покрывает 70% сценариев использования document stores. MongoDB побеждает, когда: требуется автоматическое шардирование «из коробки», схема данных меняется настолько часто, что миграции JSONB становятся болезненными, или нужен встроенный полнотекстовый поиск с Atlas Search.