.png){kind=logo}
+7 (812) 718-6184
09.10.2026
Почему PostgreSQL получил бинарный jsonb с полноценной индексацией ещё в 2014 году, а SQL Server добрался до нативного типа json только в 2025-м? И что эти 11 лет разрыва означают на практике — в архитектуре, индексах, бенчмарках и реальных запросах?
В новой статье нашего преподавателя Дарьи Чемкаевой – сравнительный разбор работы с JSON в двух СУБД.
Вывод автора: нативный json и CREATE JSON INDEX в SQL Server 2025 – это шаг вперёд по сравнению с NVARCHAR(MAX). Но по удобству, полноте и предсказуемости работы с JSON он всё ещё уступает PostgreSQL, где jsonb уже более десяти лет является полноценным типом данных с богатой экосистемой операторов и индексов. Для проектов, где JSON – основа хранения, PostgreSQL остаётся более зрелым выбором. Для гибридных сценариев в экосистеме Microsoft SQL Server 2025 – жизнеспособная альтернатива, но с оговорками.
Полный текст на Гитхаб: https://github.com/LSIND/database-notes/tree/master/common/09-2026-json-evolution
В новой статье нашего преподавателя Дарьи Чемкаевой – сравнительный разбор работы с JSON в двух СУБД.
Что внутри:
- Исторический таймлайн. Путь PostgreSQL – от текстового json (2012) через революционный jsonb (2014) и SQL/JSON Path (2019) к индексам по выражениям. Путь SQL Server – от NVARCHAR(MAX) с функциями JSON_VALUE и OPENJSON (2016) к долгожданному нативному типу (2024–2025).
- Индексы. Как устроен CREATE JSON INDEX в SQL Server 2025 – внутренняя таблица с дублированием данных, sql_variant, ограничение в один индекс на столбец и блокировка Sch-M при перестроении. Против классического инвертированного GIN-индекса PostgreSQL – компактного, универсального, без дублирования и с поддержкой всех операторов класса jsonb_ops.
- Кейсы на 1 000 000 JSON-документов: bulk-операции, размер хранилища, производительность чтения с индексом и без.
- Практические примеры кода для обеих СУБД – создание таблиц, извлечение скалярных значений, фильтрация по массивам, частичные обновления через .modify() и jsonb_set(), подсчёт элементов массива.
- Подводные камни. Почему JSON-индекс работает только с JSON_CONTAINS? Почему поиск по строковым значениям уходит в полное сканирование из-за коллации? И почему OPENJSON с CROSS APPLY на миллионе документов падает с ошибкой 701 (insufficient memory), тогда как jsonb_array_length() в PostgreSQL возвращает результат одной строкой без материализации.
Вывод автора: нативный json и CREATE JSON INDEX в SQL Server 2025 – это шаг вперёд по сравнению с NVARCHAR(MAX). Но по удобству, полноте и предсказуемости работы с JSON он всё ещё уступает PostgreSQL, где jsonb уже более десяти лет является полноценным типом данных с богатой экосистемой операторов и индексов. Для проектов, где JSON – основа хранения, PostgreSQL остаётся более зрелым выбором. Для гибридных сценариев в экосистеме Microsoft SQL Server 2025 – жизнеспособная альтернатива, но с оговорками.
Полный текст на Гитхаб: https://github.com/LSIND/database-notes/tree/master/common/09-2026-json-evolution