SQL против NoSQL в 2025: кто ещё верит, что «схема — это тормоз»?

Согласен на все сто. Маркетинг и лень — 90% кейсов, где NoSQL тащат в прод без необходимости. Реальный профит вылезает только там, где у тебя не просто «много данных», а зверский профиль нагрузки с горизонтальным шардированием на уровне ядра. Классика — event sourcing или очереди с идемпотентным чтением, где Cassandra или Scylla дают линейный скейл на запись без боли с партиционированием, которую ты бы выносил на SQL годами. Но вот только 99% проектов, где я это видел, упирались в то, что им нужна была нормальная аналитика и консистентность — и они в итоге городили костыли поверх NoSQL, либо переезжали обратно на Postgres с партициями и Redis впереди. Так что да, если у тебя нет миллиона TPS на запись и требования к аптайму 99.99% — SQL + кеш закрывает всё, а «гибкая схема» — это просто способ отложить рефакторинг до момента, когда он станет в три раза дороже.

Полностью поддерживаю. «Гибкая схема» — это не фича, а отсроченный техдолг, который выстрелит тебе в колено на миграции данных, когда прод уже живет. Если ты не упираешься в физический предел одной ноды на запись или не строишь глобально распределенную систему с офлайн-репликами — NoSQL просто перекладывает боль с одного места на другое. У меня был кейс, где взяли MongoDB для каталога с «плавающей» структурой товаров. Через год, когда понадобилась выборка по динамическим атрибутам с аггрегациями, мы потратили больше времени на маппинг и костыли, чем заняло бы проектирование EAV или JSONB в Postgres с индексами. Сейчас я наоборот смотрю в сторону SQLite в embedded-режиме или Postgres в качестве универсального молотка. Если тебе реально нужно горизонтальное масштабирование записи — бери Scylla или Cassandra, но будь готов, что аналитика и JOINы умрут, и придется строить отдельный пайплайн для отчетов. Маркетинг «NoSQL для всего» — это просто способ продать курс по новой технологии, а не решить бизнес-задачу.

Согласен, но с одной оговоркой: «схема — тормоз» умирает только в головах тех, кто никогда не делал продакшен-миграцию с ломающимися данными. В 2025 году Postgres с JSONB и частичными индексами закрывает 90% кейсов, ради которых раньше тащили MongoDB. Вопрос не в том, «SQL или NoSQL», а в том, умеешь ли ты моделировать данные под конкретную нагрузку, а не под модный тренд. Если тебе нужен именно горизонтальный шардинг записи — окей, Cassandra или Scylla, но тогда готовься к тому, что твоя отчетность превратится в отдельный сервис с выгрузкой в ClickHouse или тот же Postgres. А «гибкая схема» — это как играть в Dark Souls без щита: можно, но зачем, если есть нормальный билд? Я бы добавил, что в 2025-м даже «NoSQL-ребята» все чаще прикручивают валидацию на уровне приложения или внешние схемы типа JSON Schema, просто чтобы не стрелять себе в ногу при каждом рефакторинге. Так что да, схема — это не тормоз, это страховка.

Соглашусь с обоими, но добавлю ложку дёгтя в эту идиллию. Все эти «Postgres с JSONB закрывает 90% кейсов» — красивая мантра, пока ты не уткнулся в стоимость согласованности на запись при реальном партиционировании или не попытался построить мультирегиональную систему с активной-активной репликацией. Там NoSQL не «гибкая схема», а единственный способ не сойти с ума от конфликтов, и я говорю не про маркетинг, а про CRDT и векторные часы, которые в SQL-мире придётся изобретать велосипед заново. Но ключевая мысль ветки верна: выбор — это не религия, а инженерный трейд-офф. Если у тебя каталог с изменяемыми атрибутами и ты не собираешься пересекать границу одной ноды по записи — бери Postgres и не мучайся. Если же ты строишь глобальный event-sourcing с эвентами, которые живут вечно, — Cassandra с её компостируемыми партициями даст фору любому SQL под нагрузкой. Проблема не в технологиях, а в том, что 90% команд не моделируют нагрузку до того, как выбрать стек, а потом постфактум ищут «правильный ответ» на форумах. Хотите сэкономить годы — сначала посчитайте RPS на запись, latency-бюджет и сценарий миграции данных, а потом уже решайте, нужна ли вам «гибкость» ценой администрирования кластера. 😉