Когда данных и нагрузки становится столько, что одна база на одном сервере уже не тянет, встаёт вопрос: как масштабировать саму базу? В Yandex Cloud ответ на этот случай — YDB (Yandex Database), распределённая база, которая размазывается по многим узлам и растёт горизонтально. Разберём, что это и когда её брать вместо обычной управляемой PostgreSQL.

Что такое YDB

YDB — это распределённая база данных: её данные автоматически разложены по множеству узлов, и она масштабируется, добавляя узлы, а не увеличивая один сервер. При этом — и в этом её главная фишка — YDB поддерживает SQL (диалект YQL) и распределённые ACID-транзакции с строгой согласованностью. То есть вы работаете почти как с привычной реляционной базой (таблицы, запросы, транзакции), но без потолка одного сервера.

Это отличает YDB от многих NoSQL-баз, которые ради масштаба жертвуют транзакциями и согласованностью. Ближайший аналог в AWS — DynamoDB, но с важной разницей: DynamoDB — это в основном доступ по ключу и заранее спроектированным индексам, а YDB даёт полноценный SQL и распределённые транзакции между строками и таблицами.

Serverless и dedicated

У YDB два режима, и выбор между ними — первое решение.

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

Начинают обычно с serverless (дёшево и без забот), а на dedicated переходят, когда нагрузка выросла и стала постоянной.

Когда YDB, а когда PostgreSQL

Обе базы — реляционные и обе про SQL, поэтому важно не перепутать нишу.

Берите Managed PostgreSQL, когда: классическое приложение, данные помещаются на один (пусть и мощный) сервер, нужны богатые возможности PostgreSQL — расширения, сложные типы, полнотекстовый поиск, зрелая экосистема. Это разумный выбор по умолчанию для большинства сервисов.

Берите YDB, когда: нагрузка и объём данных перерастают один сервер, нужен горизонтальный масштаб без ручного шардирования, при этом вы не готовы отказываться от транзакций и согласованности. Типичные сценарии — высоконагруженные OLTP-системы, счётчики и события в больших объёмах, сервисы с непредсказуемым ростом.

Практический совет новичку: не берите YDB «на будущее». Если данные спокойно живут на одном сервере, PostgreSQL проще и привычнее. YDB оправдывает себя именно там, где масштаб уже упёрся в потолок одной машины.

Где это применяется

YDB закрывает нишу «нужна реляционная семантика, но и масштаб больше одного сервера» — то, ради чего раньше приходилось вручную шардировать базу и терять транзакции между шардами. В связке с serverless она особенно естественна: функция без сервера + база без сервера дают систему, которая масштабируется и тарифицируется целиком по факту.

Типичные ошибки новичков:

  • берут YDB для маленького сервиса — там, где PostgreSQL проще и богаче;
  • ждут от неё полной совместимости с PostgreSQL — это своя база со своим диалектом, а не замена «один в один»;
  • выбирают dedicated с самого старта — для нерегулярной нагрузки serverless и дешевле, и проще.

Что учить дальше: обычные реляционные и кэширующие сервисы — в управляемых данных; как обращаться к базам из кода — в интеграции со Spring Boot; общие принципы выбора хранилища не привязаны к облаку — их разбирает раздел системного дизайна. Сравнить подход можно с NoSQL-базой AWS — DynamoDB.