Сравнение PostgreSQL и YDB, отличия и что дает переход

Вопрос про YDB нам задают все чаще. Обычно он звучит примерно так: «У нас растет нагрузка, стоит ли смотреть в сторону распределенной СУБД?»

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

Сильные стороны PostgreSQL

PostgreSQL развивается с 1996 года, и к 2026-му ей исполняется ровно тридцать лет. Сейчас в промышленной эксплуатации восемнадцатая версия, девятнадцатая готовится к выходу. Развитием занимается международное сообщество, а не отдельная компания, а свободная лицензия не ограничивает коммерческое использование и не привязывает вас к вендору.

Что она умеет.

Полноценный SQL. Общие табличные выражения, оконные функции, коррелированные подзапросы, соединения по любым условиям, внешние ключи, триггеры, процедурные языки.

Богатую работу с индексами. Шесть типов индексов и несколько модификаторов, включая частичные и функциональные, покрывают почти любой сценарий поиска.

Расширяемость. PostGIS для геоданных, pgvector для векторного поиска, TimescaleDB для временных рядов и еще тысячи расширений под конкретные задачи.

Доступность экспертизы. Найти администратора или разработчика со знанием PostgreSQL несложно, документация есть на русском, а типовые проблемы давно описаны и решены.

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

Ограничения тоже понятны и никем не скрываются. Горизонтальное масштабирование обеспечивают внешние компоненты: пулер соединений, менеджер отказоустойчивого кластера, решения для шардирования. Механизм многоверсионности хранит старые версии строк рядом с актуальными, поэтому очистка требует внимания, а на очень больших базах с высокой активностью транзакций может за ней не успевать.

Как устроена YDB

YDB относится к классу Distributed SQL. Систему разработали в Яндексе для внутренних задач, в 2018 году она вышла на рынок как облачный сервис, в 2022-м открыли исходный код. Продукт входит в реестр отечественного ПО.

Архитектура здесь принципиально другая.

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

Центрального узла нет. Все узлы равноправны и принимают запросы одновременно.

Секционирование динамическое. Таблицы делятся по диапазонам первичного ключа. Когда секция перерастает порог по объему или нагрузке, система разбивает ее автоматически, а при снижении нагрузки собирает обратно.

Транзакции распределенные и полностью ACID. Строгая согласованность обеспечивается без классического двухфазного коммита.

Репликация между дата-центрами синхронная. В конфигурации на три площадки заявленный уровень доступности достигает 99,99%.

Мультитенантность встроена. В одном кластере размещаются сотни изолированных баз с общим хранилищем и квотами на процессор, память и дисковые операции.

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

Восемь параметров сравнения YDB с PostgreSQL

1. Один сервер против кластера

PostgreSQL спроектирована как одноузловая система: основной сервер, реплики для чтения и отказоустойчивости. Кластеризация, шардирование и балансировка добавляются поверх.

YDB изначально создавалась под кластер и раскрывается на десятках серверов в нескольких дата-центрах. На трех узлах она тоже работает, но это минимальная конфигурация, а не целевая.

Отсюда простой вывод: разворачивать YDB ради базы на 200 ГБ смысла мало. Порог входа и требования к экспертизе заметно выше, а выигрыша при таких объемах не будет.

2. Отличия PostgreSQL и YDB в модели данных

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

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

Отсюда важное следствие. Типовая схема из PostgreSQL с автоинкрементными идентификаторами в YDB запустится, но работать будет плохо. Схему логичнее перепроектировать заново, чем переносить как есть.

3. SQL против YQL

YDB использует собственный диалект YQL. Он близок к стандартному SQL, но отличия существенные:

• общие табличные выражения не поддерживаются, вместо них используются именованные выражения;
• коррелированных подзапросов нет, конструкции с ними переписываются через соединения и группировки;
• соединения возможны только по равенству, условия с неравенствами приходится обходить;
• триггеров и хранимых процедур нет, официальный курс YDB для разработчиков так и формулирует задачу — строить надежные системы без них;
• ссылочная целостность обеспечивается на стороне приложения, декларативных проверок в распределенной модели не предусмотрено.

Расширяемость в понимании PostgreSQL в YDB отсутствует как класс. Взамен есть запросы к внешним системам, включая саму PostgreSQL, MySQL, Greenplum, ClickHouse и объектные хранилища.

4. Индексы и поиск по данным

PostgreSQL предлагает шесть типов индексов и несколько модификаторов. У YDB это вторичные индексы, глобальные и, как правило, неуникальные, плюс векторные для приближенного поиска.

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

5. Кто отвечает за повторы транзакций

Обе системы дают ACID, но реализация разная, и это заметно влияет на код приложения.

YDB работает на оптимистических блокировках. При конфликте транзакция отменяется, и повтор придется реализовать в приложении. В PostgreSQL с блокировками на уровне строк такой необходимости в большинстве сценариев не возникает.

Кроме того, у YDB есть жесткие лимиты на объем данных в одной транзакции и на размер результата одного запроса. Для распределенной системы это разумно, но привычные приемы работы с большими выборками придется пересматривать.

6. Отказоустойчивость и репликация

Здесь преимущество YDB очевидно, и спорить с этим нет смысла. PostgreSQL предлагает потоковую, синхронную, каскадную и логическую репликацию, но кластер собирается из внешних компонентов, а геораспределенная синхронная запись остается отдельной инженерной задачей под каждый проект.

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

7. Безопасность и требования регуляторов

По PostgreSQL картина понятная: публичный реестр уязвимостей, предсказуемый цикл обновлений, а защищенные редакции добавляют маскирование данных, прозрачное шифрование, разграничение прав привилегированных пользователей и сертификацию по 4-му уровню доверия.

YDB входит в реестр отечественного ПО, но по части сертификации ФСТЭК ситуация скромнее, чем у зрелых защищенных редакций PostgreSQL. Этот пункт лучше проверять отдельно под конкретный проект и конкретную дату.

8. Экосистема и сообщество

Самый недооцененный пункт в любом сравнении. Вокруг PostgreSQL тридцать лет накопленных инструментов, расширений, книг, конференций и специалистов на рынке труда. Почти на любой вопрос есть готовый ответ.

YDB открытой стала недавно, и экосистема вокруг нее пока формируется: меньше специализированных инструментов, плагинов и людей с реальным опытом. Это означает, что при внедрении придется больше опираться на собственную команду, а поиск решений для нетривиальных ситуаций занимает больше времени.

Из того, что уже работает: драйверы и SDK для основных языков, коннекторы к популярным BI-системам, поддержка стандартных инструментов версионирования схемы, встроенный веб-интерфейс.

Коротко о различиях

Параметр	PostgreSQL	YDB
Класс системы	Классическая реляционная СУБД, один узел плюс реплики	Distributed SQL, кластер как норма
Масштабирование	В основном вертикальное, горизонтальное через внешние решения	Горизонтальное встроено, узлы добавляются на лету
Язык запросов	Полный SQL с табличными выражениями и подзапросами	YQL, часть привычных конструкций недоступна
Первичный ключ	Необязателен, обычно автоинкремент	Обязателен и определяет шардирование
Индексы	Шесть типов плюс частичные и функциональные	Вторичные и векторные, у колоночных таблиц индексов нет
Транзакции	Блокировки на уровне строк, повторы обычно не нужны	Оптимистические блокировки, повторы реализует приложение
Триггеры и процедуры	Полная поддержка на нескольких языках	Отсутствуют, логика переносится в приложение
Отказоустойчивость	Собирается из внешних компонентов	Встроенная репликация на три площадки
Расширения	Тысячи, включая PostGIS и pgvector	Нет, вместо них запросы к внешним источникам
Реестр отечественного ПО	Защищенные редакции входят, ванильная нет	Входит
Порог входа	Низкий, специалистов много	Высокий, специалистов заметно меньше

Хотите понять, как эта таблица ложится на вашу систему?

Начните с оценки того, что у вас уже есть. Конвертум Сканер подключается к базе с правами только на чтение, считает объекты, объем и строки кода и формирует отчет по сложности перехода. Инструмент бесплатный, изменений в базу не вносит.

Сравнение производительности PostgreSQL и YDB

Если коротко про PostgreSQL, YDB, производительность на сопоставимом железе у них почти одинаковая. Разница появляется при масштабировании кластера, и там она уже существенная.

Как выглядит сравнение YDB с PostgreSQL по скорости

Самые содержательные открытые данные это серия тестов TPC-C на Benchbase, где сравнивали PostgreSQL 18 и YDB 24.3. Стенды для PostgreSQL и трехузловой YDB были идентичны по железу: два сокета Intel Xeon Silver 4114, 192 ГБ памяти, накопители NVMe, сеть 25 Гбит/с.

Результаты выглядят так:

• PostgreSQL, один сервер плюс синхронная реплика: 5000 складов, 56 024 tpmC, эффективность 87,1%.
• YDB на трех серверах, синхронный режим: 5300 складов, 58 594 tpmC, эффективность 86,0%.
• YDB на трех серверах, асинхронный режим: 5500 складов, 61 104 tpmC.
• YDB на девяти серверах, шесть узлов обработки: 8000 складов, 96 564 tpmC.
• YDB на девяти серверах, девять узлов обработки: 12 000 складов, 148 914 tpmC, эффективность 96,5%.

К этим числам есть три существенных комментария.

Первое. На одинаковом оборудовании разница укладывается в 5%, то есть ее почти нет. Тезис «YDB быстрее» на трех узлах не подтверждается. Подтверждается другой: YDB не медленнее при иначе устроенной отказоустойчивости.

Второе. Тест масштабируемости на девяти узлах проводили на более слабом железе: процессоры 2014 года вместо 2017-го, обычные твердотельные накопители вместо NVMe, сеть вдвое медленнее. И даже так девять узлов дали кратно больше операций при меньшей задержке. Рост близок к линейному, и это главный аргумент в пользу распределенной архитектуры.

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

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

Что стало с совместимостью PostgreSQL и YDB

Это самое важное изменение последнего времени, и о нем часто пишут неверно, опираясь на устаревшие материалы.

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

Что это меняет для команды. Подключиться к YDB привычными клиентами и драйверами PostgreSQL больше нельзя. Вместо них используются собственные инструменты YDB: командная строка, встроенный интерфейс, SDK и отдельный драйвер. Вместо синтаксиса PostgreSQL идет YQL, вместо BI-инструментов через протокол PostgreSQL нативные коннекторы.

Часть возможностей все же сохранилась. Из YDB по-прежнему можно обращаться запросами к внешним кластерам PostgreSQL, а внутри YQL доступны функции в стиле PostgreSQL и опциональные типы колонок.

Общий смысл простой: рассчитывать на «переключили строку подключения и поехали» не получится. Совместимости на уровне протокола больше нет, и это ключевой фактор при оценке бюджета проекта.

Что придется переписать при миграции с PostgreSQL на YDB

Миграция PostgreSQL в YDB это не столько перенос базы, сколько переработка слоя доступа к данным. Работа делится на три части, и только одна из них про сами данные.

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

Запросы. Все, что использует табличные выражения, коррелированные подзапросы, соединения по неравенству и постраничный вывод через смещение, переписывается под YQL.

Приложение. Драйвер меняется на собственный драйвер YDB. Добавляется обязательная логика повторов транзакций. Пересматриваются размеры пакетов записи.

Перенос PostgreSQL в YDB на этом фоне оказывается самой механической и предсказуемой частью проекта. Основной бюджет уходит на переписывание кода, а не на данные.

Как перенести PostgreSQL на YDB

1. Оценить схему и запросы. До начала работ полезно провести инвентаризацию: какие таблицы без первичного ключа, где возрастающие ключи, какие запросы используют неподдерживаемые конструкции. Это и определит объем переработки.
2. Перенести структуру и данные. Импорт PostgreSQL в YDB выполняется штатной утилитой, которая подключается к источнику, формирует структуру целевых таблиц, создает их и заливает данные в несколько параллельных потоков. Полезно знать заранее, что вторичные индексы утилита не переносит и создавать их придется отдельно.
3. Альтернатива для больших объемов. Документация советует выгрузить данные в CSV в объектное хранилище и загрузить их оттуда, так чтение распараллеливается эффективнее.
4. Непрерывная репликация. Для потокового переноса изменений применяют инструменты захвата изменений или классические ETL-фреймворки.
5. Версионирование схемы. Популярные инструменты миграций схемы поддерживают диалект YDB, так что этот этап встраивается в привычный CI/CD.
6. Постепенное переключение. Разумная схема выглядит так: сначала YDB подключается как дополнительное хранилище с записью в обе базы, чтение идет с обращением к PostgreSQL, если данных еще нет, затем догоняются оставшиеся записи, и только потом PostgreSQL выводится из контура. Резкое переключение на таких проектах почти никогда не оправдано.

Переписывание схемы и кода можно автоматизировать

Конвертум Мастер конвертирует таблицы, процедуры, функции, пакеты, триггеры и представления, а после работы показывает отчет: что прошло автоматически, а что требует доработки руками. По нашим проектам уровень автоматизации составляет от 90 до 96%. Работает локально, данные не покидают ваш контур. Демо-лицензия на 30 дней доступна без предоплаты.

Шесть вопросов, которые помогут выбрать PostgreSQL или YDB

Какой объем и какая нагрузка? Если данные помещаются в один сервер, а нагрузка измеряется сотнями конкурентных соединений, оставайтесь на PostgreSQL. YDB для высоконагруженных систем оправдана там, где нужны десятки терабайт и рост, который одним сервером уже не закрыть: платежные ядра, биллинг, крупный e-commerce, промышленный интернет вещей.

Что с отказоустойчивостью? Если нужна работа при отказе целого дата-центра без ручных переключений, это сильная сторона распределенной архитектуры. Если достаточно синхронной реплики и автоматического переключения, PostgreSQL проще, дешевле и предсказуемее в эксплуатации.

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

Есть ли команда? Нужны люди, готовые разбираться в первичных ключах как в инструменте шардирования, в оптимистических блокировках и в лимитах распределенных транзакций. Без такой команды вопрос «YDB или PostgreSQL» решается сам собой не в пользу распределенной системы.

Что требует регулятор? Обе опции представлены в реестре отечественного ПО, но у PostgreSQL это защищенные редакции, а не ванильная сборка. Сертификацию проверяйте под конкретный продукт и редакцию.

На каком этапе проект? Для нового сервиса, про который пока неизвестно, как он вырастет, PostgreSQL остается правильным стартом. Переезжать потом будет дороже, но и платить за неиспользуемую распределенность с первого дня незачем.

Если коротко ответить, что лучше, PostgreSQL или YDB, то напрямую они не конкурируют. Это разные классы систем, и в зрелых ландшафтах они работают рядом. Показательно, что документация YDB не советует смешивать транзакционные и аналитические нагрузки даже внутри нее самой: тяжелый аналитический запрос забирает ресурсы кластера, и короткие транзакции начинают ждать. Разделение контуров остается хорошей практикой в любой архитектуре.

Что мы советуем клиентам

PostgreSQL это универсальный инструмент с тридцатилетней зрелостью, полноценным SQL и огромной экосистемой. Для абсолютного большинства проектов ее возможностей хватает с запасом, а при грамотной настройке секционирования, репликации и очистки она уверенно работает на объемах, которые многие заранее считают неподъемными.

YDB решает конкретную задачу: линейный рост под нагрузкой, которую физически не вытянет один сервер, и работа при отказе целого дата-центра. Цена решения тоже конкретная. Ограниченный диалект SQL, обязательные ключи-шарды, повторы транзакций в коде, отсутствие триггеров и процедур, отсутствующая совместимость по протоколу.

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

Разберем вашу задачу вместе

Команда Конвертум занимается только миграцией баз данных и конвертацией приложений. Мы работаем с PostgreSQL, Postgres Pro, Oracle, SQL Server, Sybase, Db2 и Informix, проходим проект от первой оценки до вывода в эксплуатацию и фиксируем объем, сроки и стоимость до старта.

Услуги Конвертум по миграции баз данных