Юлий Гольдберг: Lakehouse — уже не экспериментальное направление
Отечественный рынок СУБД прошел путь от экстренного импортозамещения к более зрелой стадии, когда на первый план выходят технологическая и экономическая целесообразность. Заказчики все реже ищут просто «российскую альтернативу» — они выбирают платформу для архитектуры данных, аналитики и ИИ-сценариев. В интервью руководитель направления GlowByte Юлий Гольдберг отвечает на вопросы об эволюции рынка СУБД в РФ, переходе к Lakehouse, роли Postgres и барьерах для отечественных вендоров.
— Как вы оцениваете текущее состояние российского рынка СУБД? Можно ли говорить, что рынок уже прошел этап срочного импортозамещения и перешел к более зрелому развитию?
Замена СУБД в критических системах, таких как ERP (система планирования ресурсов предприятия) или хранилище данных, — это очень сложный, дорогой и длительный проект. Поэтому выполняют такую замену обычно только в случае крайней необходимости. На наиболее популярные СУБД, такие как Oracle и MS SQL, вендоры в основном предоставляли постоянные лицензии, а не годовую подписку. Таким образом, в большинстве проектов срочной потребности в замене СУБД из-за отключения после 2022 года не возникло. Замена идет планово, с детальной оценкой альтернативных технологий, стоимости лицензий, миграции и потенциальных рисков, особенно в случае с открытыми технологиями. На проектах GlowByte мы видим, что, вопреки распространенному мнению, многие крупные заказчики не торопятся отказываться от Oracle и MS SQL.
Другая ситуация сложилась там, где были развернуты ПАКи — например, Teradata и Oracle Exadata. Даже если лицензия продолжала действовать и серверы не отключились, у клиентов пропала возможность расширения мощностей. Поскольку объем данных за прошедшие годы существенно вырос, продолжать использовать такие ПАКи без возможности обновления стало крайне сложно. Большинство их владельцев либо полностью мигрировали на альтернативные СУБД, либо как минимум запустили новые СУБД параллельно с "замороженными" кластерами.
— С какими трудностями заказчики чаще всего сталкиваются при переходе с зарубежных СУБД на российские решения?
Наиболее частые проблемы — это более низкая производительность, отсутствие важных функций (например, связанных с управлением нагрузкой или правами доступа), несоответствие диалекта SQL и необходимость переписывать реализованные на другой СУБД процессы и системы, ну и, конечно, необходимость переучивать и переформатировать команду. Все эти трудности преодолимы. Примеров миграции много, во всех областях — и в автоматизированных банковских системах (АБС), и в корпоративных системах управления, и в ХД, но зачастую на миграцию требуется очень много ресурсов, что приводит к растягиванию таких проектов на годы, смене ответственных и даже целых команд.
В целом гораздо правильнее не просто заменить одну СУБД на другую, а привязать миграцию к существенному изменению подходов, процессов, архитектуры, нацеленных на улучшение пользовательского опыта и решение новых задач, которые на старой СУБД были фактически недоступны. Хороший пример из опыта GlowByte. Если клиент построил свое ХД на Teradata и после мигрировал его на Greenplum, то, скорее всего, после большого и тяжелого проекта никаких преимуществ он не получит. Скорее даже возникнут дополнительные ограничения, а производительность и надежность может пострадать. А если клиент мигрирует из той же Teradata и классического «инмонского» ХД в парадигму Lakehouse, то он сразу получает множество преимуществ, что позволяет гораздо проще обосновать проект и даже со временем окупить его.
— Какие зарубежные СУБД сложнее всего заменить в крупных корпоративных ландшафтах и почему?
Наиболее сложно заменить те СУБД, которые используются в унаследованных (legacy) системах, разработчики которых давно канули в лету и не поддерживают свои продукты. Переписывать такие системы никто не будет, поэтому тут остается только вариант их полной замены.
Замена СУБД в критических системах, таких как ERP (система планирования ресурсов предприятия) или хранилище данных, — это очень сложный, дорогой и длительный проект. Поэтому выполняют такую замену обычно только в случае крайней необходимости. На наиболее популярные СУБД, такие как Oracle и MS SQL, вендоры в основном предоставляли постоянные лицензии, а не годовую подписку. Таким образом, в большинстве проектов срочной потребности в замене СУБД из-за отключения после 2022 года не возникло. Замена идет планово, с детальной оценкой альтернативных технологий, стоимости лицензий, миграции и потенциальных рисков, особенно в случае с открытыми технологиями. На проектах GlowByte мы видим, что, вопреки распространенному мнению, многие крупные заказчики не торопятся отказываться от Oracle и MS SQL.
Другая ситуация сложилась там, где были развернуты ПАКи — например, Teradata и Oracle Exadata. Даже если лицензия продолжала действовать и серверы не отключились, у клиентов пропала возможность расширения мощностей. Поскольку объем данных за прошедшие годы существенно вырос, продолжать использовать такие ПАКи без возможности обновления стало крайне сложно. Большинство их владельцев либо полностью мигрировали на альтернативные СУБД, либо как минимум запустили новые СУБД параллельно с "замороженными" кластерами.
— С какими трудностями заказчики чаще всего сталкиваются при переходе с зарубежных СУБД на российские решения?
Наиболее частые проблемы — это более низкая производительность, отсутствие важных функций (например, связанных с управлением нагрузкой или правами доступа), несоответствие диалекта SQL и необходимость переписывать реализованные на другой СУБД процессы и системы, ну и, конечно, необходимость переучивать и переформатировать команду. Все эти трудности преодолимы. Примеров миграции много, во всех областях — и в автоматизированных банковских системах (АБС), и в корпоративных системах управления, и в ХД, но зачастую на миграцию требуется очень много ресурсов, что приводит к растягиванию таких проектов на годы, смене ответственных и даже целых команд.
В целом гораздо правильнее не просто заменить одну СУБД на другую, а привязать миграцию к существенному изменению подходов, процессов, архитектуры, нацеленных на улучшение пользовательского опыта и решение новых задач, которые на старой СУБД были фактически недоступны. Хороший пример из опыта GlowByte. Если клиент построил свое ХД на Teradata и после мигрировал его на Greenplum, то, скорее всего, после большого и тяжелого проекта никаких преимуществ он не получит. Скорее даже возникнут дополнительные ограничения, а производительность и надежность может пострадать. А если клиент мигрирует из той же Teradata и классического «инмонского» ХД в парадигму Lakehouse, то он сразу получает множество преимуществ, что позволяет гораздо проще обосновать проект и даже со временем окупить его.
— Какие зарубежные СУБД сложнее всего заменить в крупных корпоративных ландшафтах и почему?
Наиболее сложно заменить те СУБД, которые используются в унаследованных (legacy) системах, разработчики которых давно канули в лету и не поддерживают свои продукты. Переписывать такие системы никто не будет, поэтому тут остается только вариант их полной замены.
В качестве примера можно привести ряд АБС российских и зарубежных производителей, которые до сих пор используются в российских банках. Если же вендор «жив», то даже высоконагруженные ключевые системы со временем можно перевести на новые СУБД.
Если говорить о конкретных СУБД, то замену наиболее распространенных на рынке Oracle и MS SQL можно считать уже отработанным процессом. Примеров миграций множество. Но от этого процесс миграции не становится простым. Дополнительные сложности обычно создает жесткое встраивание СУБД в прикладную систему. Например, SAP и Hana. Очевидно, что заменить Hana можно только полностью отказавшись от SAP. Другой пример — MS SQL и его экосистема в виде SSIS, SSRS, SSAS. Просто перейти с MS SQL на Postgres именно как СУБД вполне реально, но если используется, например, еще и SSAS, то при миграции придется отказаться и от него, а для этого потребуется найти альтернативный OLAP (инструмент многомерного анализа данных) с сопоставимой функциональностью и производительностью, что не так уж просто.
— Насколько российские СУБД сегодня закрывают требования крупных заказчиков по производительности, отказоустойчивости, безопасности, масштабируемости и удобству администрирования?
В целом можно сказать, что закрывают. В первую очередь, потому что сами требования приводятся заказчиками в соответствие с реалиями имеющегося на рынке ПО. Нет смысла требовать от Postgres точно таких же возможностей, что и в Oracle, например. Если оптимизатор запросов или механизм их распараллеливания в Oracle из коробки лучше, то соответственно разработчикам на Postgres приходится больше думать головой, тратить больше времени на оптимизацию и продумывание архитектуры. Зато есть российские СУБД с сертификатом ФСТЭК и даже ФСБ. Требования к наличию таких сертификатов предъявляет все больше заказчиков и не только государственных.
— Сохраняется ли заметная доля зарубежных СУБД в российских компаниях? Если да, что мешает заказчикам отказаться от них полностью?
Да, у многих заказчиков все еще сохраняется как минимум часть парка СУБД от иностранных вендоров. Проекты по миграции сложные и затратные, лицензии на СУБД постоянные, ПО уже настолько «вылизано», что поддержка вендора во многих случаях не требуется. Если нет явного экономического или хотя бы технологического эффекта от такого проекта, то получить согласование на него от владельцев бюджета непросто. Мы в GlowByte обычно не просто меняем одну СУБД на другую, а мигрируем саму систему на новую с импортозамещенной СУБД. Или, к примеру, переводим хранилище данных на совершенно новую парадигму — Lakehouse, что дает заказчику существенные выгоды и позволяет сначала обосновать, а потом и окупить проект.
— Какой главный технологический тренд на рынке СУБД вы бы выделили на ближайшие 2−3 года?
Компания GlowByte больше занимается не транзакционными системами, а аналитическими, поэтому в первую очередь мы имеем дело с аналитическими СУБД. Современный тренд в этой области обозначился достаточно четко: это переход от монолитных СУБД, в которых и хранение, и обработка данных проводились в одном продукте — например, Oracle, MS SQL, Teradata, — к концепции Lakehouse. В ее рамках система хранения данных (обычно S3+Parquet/Iceberg) отделена от систем обработки, которых может быть несколько, каждая для своих целей: Spark — для загрузки и трансформации, Trino — для гетерогенного доступа, Impala — для быстрых ad hoc (нерегламентированных) запросов к данным на SQL. Это новый подход, который был выдвинут крупнейшими мировыми интернет-гигантами, но он уже прижился в России.
Подход доказал свою состоятельность. GlowByte совместно с Data Sapience за прошедшие три года сделали уже более 15 проектов, и крупнейшие достигли объемов в несколько петабайт данных. На практике подтвердилась как технологическая, так и экономическая состоятельность этой архитектуры.
- Меняется ли роль СУБД в корпоративной архитектуре?
СУБД в новой парадигме Lakehouse — это уже не монолит, а набор взаимодополняющих компонентов: отдельно система хранения, отдельно обработка данных, отдельно управление метаданными, отдельно управление правами доступа и так далее. С одной стороны, такой подход гораздо гибче: можно из «кирпичиков» построить ровно то, что требуется, и не платить за лишние ресурсы. Но при этом, безусловно, возрастает нагрузка на архитекторов и DevOps-инженеров (специалистов по разработке и эксплуатации).
— Насколько российские СУБД сегодня закрывают требования крупных заказчиков по производительности, отказоустойчивости, безопасности, масштабируемости и удобству администрирования?
В целом можно сказать, что закрывают. В первую очередь, потому что сами требования приводятся заказчиками в соответствие с реалиями имеющегося на рынке ПО. Нет смысла требовать от Postgres точно таких же возможностей, что и в Oracle, например. Если оптимизатор запросов или механизм их распараллеливания в Oracle из коробки лучше, то соответственно разработчикам на Postgres приходится больше думать головой, тратить больше времени на оптимизацию и продумывание архитектуры. Зато есть российские СУБД с сертификатом ФСТЭК и даже ФСБ. Требования к наличию таких сертификатов предъявляет все больше заказчиков и не только государственных.
— Сохраняется ли заметная доля зарубежных СУБД в российских компаниях? Если да, что мешает заказчикам отказаться от них полностью?
Да, у многих заказчиков все еще сохраняется как минимум часть парка СУБД от иностранных вендоров. Проекты по миграции сложные и затратные, лицензии на СУБД постоянные, ПО уже настолько «вылизано», что поддержка вендора во многих случаях не требуется. Если нет явного экономического или хотя бы технологического эффекта от такого проекта, то получить согласование на него от владельцев бюджета непросто. Мы в GlowByte обычно не просто меняем одну СУБД на другую, а мигрируем саму систему на новую с импортозамещенной СУБД. Или, к примеру, переводим хранилище данных на совершенно новую парадигму — Lakehouse, что дает заказчику существенные выгоды и позволяет сначала обосновать, а потом и окупить проект.
— Какой главный технологический тренд на рынке СУБД вы бы выделили на ближайшие 2−3 года?
Компания GlowByte больше занимается не транзакционными системами, а аналитическими, поэтому в первую очередь мы имеем дело с аналитическими СУБД. Современный тренд в этой области обозначился достаточно четко: это переход от монолитных СУБД, в которых и хранение, и обработка данных проводились в одном продукте — например, Oracle, MS SQL, Teradata, — к концепции Lakehouse. В ее рамках система хранения данных (обычно S3+Parquet/Iceberg) отделена от систем обработки, которых может быть несколько, каждая для своих целей: Spark — для загрузки и трансформации, Trino — для гетерогенного доступа, Impala — для быстрых ad hoc (нерегламентированных) запросов к данным на SQL. Это новый подход, который был выдвинут крупнейшими мировыми интернет-гигантами, но он уже прижился в России.
Подход доказал свою состоятельность. GlowByte совместно с Data Sapience за прошедшие три года сделали уже более 15 проектов, и крупнейшие достигли объемов в несколько петабайт данных. На практике подтвердилась как технологическая, так и экономическая состоятельность этой архитектуры.
- Меняется ли роль СУБД в корпоративной архитектуре?
СУБД в новой парадигме Lakehouse — это уже не монолит, а набор взаимодополняющих компонентов: отдельно система хранения, отдельно обработка данных, отдельно управление метаданными, отдельно управление правами доступа и так далее. С одной стороны, такой подход гораздо гибче: можно из «кирпичиков» построить ровно то, что требуется, и не платить за лишние ресурсы. Но при этом, безусловно, возрастает нагрузка на архитекторов и DevOps-инженеров (специалистов по разработке и эксплуатации).
Количество компонентов в сложном корпоративном решении исчисляется десятками, и их нужно аккуратно развернуть, интегрировать, заставить работать как единое целое. Словом, архитектура усложняется. Людям, даже закаленным профессионалам, приходится многому учиться и перестраивать мышление в соответствии с новыми подходами.
Существенно упростить и ускорить развертывание Lakehouse-архитектуры можно за счет выбора уже готового интегрированного и протестированного продукта, включающего все необходимые компоненты. К слову, пионером в области Lakehouse в РФ является Data Ocean Nova от Data Sapience, которая впервые была внедрена в промышленную эксплуатацию еще в 2022 году.
— Какие барьеры сегодня сдерживают развитие российского рынка СУБД?
Главным барьером для развития российского рынка СУБД остается его небольшой объем в денежном и количественном выражении по сравнению с мировым, а также сложность экспорта российских технологий. Российский рынок СУБД совсем небольшой относительно мирового. Продавать наши СУБД за рубеж крайне сложно из-за высокой конкуренции и сложной геополитической обстановки. Поэтому объем инвестиций в продукты несопоставим с тем, что имеют зарубежные производители. Полномасштабно развивать продукт и конкурировать с крупными зарубежными брендами в таких условиях непросто.
Практически все российские СУБД, кроме ClickHouse и Tarantool, базируются на open source продуктах (с открытым исходным кодом), которые поддерживают международные сообщества или зарубежные вендоры. Даже упомянутый ClickHouse, хотя и является изначально российской СУБД, все равно сегодня поддерживается и развивается международным сообществом. Риски того, что оно поменяет лицензию и прекратит распространять ПО как open source, велики, и мы уже наблюдаем ряд случаев, когда это произошло. Самый громкий кейс — Greenplum. Наши коллеги подробно разбирали эту ситуацию и рассказывали, как мы сохраняем доступ к исходному коду, в статье на Хабре. Словом, ограниченные инвестиционные возможности рынка — это барьер, который сложно перепрыгнуть.
— Насколько остро стоит вопрос дефицита специалистов по российским СУБД?
По распространенным СУБД, типа Postgres или ClickHouse, специалистов на рынке достаточно. Эти продукты популярны уже много лет, разработчики и администраторы не только прошли курсы, но и получили богатую практику использования этого ПО в условиях высокой нагрузки, в облаках и on-premise (на мощностях заказчика), на критических для бизнеса решениях.
В то же время, как показывает практика GlowByte, значимость специалистов технической поддержки со стороны интегратора и вендора особенно велика в проектах внедрения Lakehouse-платформ. Если СУБД знакома заказчику, у него есть центр компетенции, внутренняя документация и прочее, то потребность во внешних специалистах для поддержки в эксплуатации минимальна. Поэтому и существует множество клиентов, которые до сих пор «сидят» на Oracle или MS SQL и самостоятельно решают все свои проблемы.
Но если компания внедряет новую для себя СУБД, тем более новую концепцию работы с данными, то требуется более значительная помощь со стороны вендора и интегратора. Мы в GlowByte это видим, например, по проектам внедрения Lakehouse-платформы данных Data Ocean Nova. Поэтому мы предоставляем расширенную поддержку не только в части эксплуатации самой системы, но и помогаем создавать собственный центр компетенции внутри организации.
Переход на новую СУБД — отдельная большая задача, особенно когда в хранилище накоплены сотни терабайт данных и на старую систему завязаны десятки систем-источников и потребителей информации. Приходится какое-то время обеспечивать параллельную эксплуатацию старой и новой систем и при этом с минимальным отвлечением специалистов, которые на 200% загружены миграцией. Для решения такой задачи вендор Data Sapience разработал специальный модуль Data Ocean Flex Loader: он позволяет первоначально загрузить историю, а затем на ежедневной основе сначала подпитывает новую платформу из старой, а после — наоборот, для обеспечения работы legacy-приложений (унаследованных систем).
— Как развитие ИИ влияет на рынок СУБД?
На требования к СУБД оказывает влияние развитие искусственного интеллекта. ИИ (сейчас обычно под этим понимают использование больших языковых моделей — LLM и AI-агентов) работает в основном с неструктурированными данными — текстами, картинками и тому подобным. Эти данные СУБД должны уметь быстро обрабатывать.
Традиционные СУБД (Oracle, MS SQL, Postgres) всегда были ориентированы в первую очередь на обработку структурированной информации. Новые требования породили новые концепции — в частности Lakehouse, в основе которого лежит объектное S3-хранилище, а над ним — широкий набор движков обработки данных, каждый из которых позволяет оптимально решать свою задачу. В S3 можно положить и текстовые документы, и видеофайлы, и большие таблицы с числами, и маленькие справочники. И все это разнообразие эффективно обрабатывается с помощью требуемых инструментов, причем в рамках единого поля метаданных, с общим механизмом управления доступом и инструментом обеспечения отказоустойчивости.
— Что будет главным критерием выбора СУБД в ближайшие годы?
Прогнозируя ситуацию на 2027 год, я бы выделил несколько ключевых критериев выбора СУБД. В первую очередь это стоимость владения, затем — возможность горизонтального масштабирования для крупных компаний и отдельно — надежность облачных сервисов с полным сопровождением (managed service) для небольших игроков.
— Какие барьеры сегодня сдерживают развитие российского рынка СУБД?
Главным барьером для развития российского рынка СУБД остается его небольшой объем в денежном и количественном выражении по сравнению с мировым, а также сложность экспорта российских технологий. Российский рынок СУБД совсем небольшой относительно мирового. Продавать наши СУБД за рубеж крайне сложно из-за высокой конкуренции и сложной геополитической обстановки. Поэтому объем инвестиций в продукты несопоставим с тем, что имеют зарубежные производители. Полномасштабно развивать продукт и конкурировать с крупными зарубежными брендами в таких условиях непросто.
Практически все российские СУБД, кроме ClickHouse и Tarantool, базируются на open source продуктах (с открытым исходным кодом), которые поддерживают международные сообщества или зарубежные вендоры. Даже упомянутый ClickHouse, хотя и является изначально российской СУБД, все равно сегодня поддерживается и развивается международным сообществом. Риски того, что оно поменяет лицензию и прекратит распространять ПО как open source, велики, и мы уже наблюдаем ряд случаев, когда это произошло. Самый громкий кейс — Greenplum. Наши коллеги подробно разбирали эту ситуацию и рассказывали, как мы сохраняем доступ к исходному коду, в статье на Хабре. Словом, ограниченные инвестиционные возможности рынка — это барьер, который сложно перепрыгнуть.
— Насколько остро стоит вопрос дефицита специалистов по российским СУБД?
По распространенным СУБД, типа Postgres или ClickHouse, специалистов на рынке достаточно. Эти продукты популярны уже много лет, разработчики и администраторы не только прошли курсы, но и получили богатую практику использования этого ПО в условиях высокой нагрузки, в облаках и on-premise (на мощностях заказчика), на критических для бизнеса решениях.
В то же время, как показывает практика GlowByte, значимость специалистов технической поддержки со стороны интегратора и вендора особенно велика в проектах внедрения Lakehouse-платформ. Если СУБД знакома заказчику, у него есть центр компетенции, внутренняя документация и прочее, то потребность во внешних специалистах для поддержки в эксплуатации минимальна. Поэтому и существует множество клиентов, которые до сих пор «сидят» на Oracle или MS SQL и самостоятельно решают все свои проблемы.
Но если компания внедряет новую для себя СУБД, тем более новую концепцию работы с данными, то требуется более значительная помощь со стороны вендора и интегратора. Мы в GlowByte это видим, например, по проектам внедрения Lakehouse-платформы данных Data Ocean Nova. Поэтому мы предоставляем расширенную поддержку не только в части эксплуатации самой системы, но и помогаем создавать собственный центр компетенции внутри организации.
Переход на новую СУБД — отдельная большая задача, особенно когда в хранилище накоплены сотни терабайт данных и на старую систему завязаны десятки систем-источников и потребителей информации. Приходится какое-то время обеспечивать параллельную эксплуатацию старой и новой систем и при этом с минимальным отвлечением специалистов, которые на 200% загружены миграцией. Для решения такой задачи вендор Data Sapience разработал специальный модуль Data Ocean Flex Loader: он позволяет первоначально загрузить историю, а затем на ежедневной основе сначала подпитывает новую платформу из старой, а после — наоборот, для обеспечения работы legacy-приложений (унаследованных систем).
— Как развитие ИИ влияет на рынок СУБД?
На требования к СУБД оказывает влияние развитие искусственного интеллекта. ИИ (сейчас обычно под этим понимают использование больших языковых моделей — LLM и AI-агентов) работает в основном с неструктурированными данными — текстами, картинками и тому подобным. Эти данные СУБД должны уметь быстро обрабатывать.
Традиционные СУБД (Oracle, MS SQL, Postgres) всегда были ориентированы в первую очередь на обработку структурированной информации. Новые требования породили новые концепции — в частности Lakehouse, в основе которого лежит объектное S3-хранилище, а над ним — широкий набор движков обработки данных, каждый из которых позволяет оптимально решать свою задачу. В S3 можно положить и текстовые документы, и видеофайлы, и большие таблицы с числами, и маленькие справочники. И все это разнообразие эффективно обрабатывается с помощью требуемых инструментов, причем в рамках единого поля метаданных, с общим механизмом управления доступом и инструментом обеспечения отказоустойчивости.
— Что будет главным критерием выбора СУБД в ближайшие годы?
Прогнозируя ситуацию на 2027 год, я бы выделил несколько ключевых критериев выбора СУБД. В первую очередь это стоимость владения, затем — возможность горизонтального масштабирования для крупных компаний и отдельно — надежность облачных сервисов с полным сопровождением (managed service) для небольших игроков.
Стоимость владения, безусловно, останется важным критерием и в 2027 году. Вряд ли ситуация в экономике так драматически переменится, что ценовой фактор потеряет актуальность. Для крупных растущих компаний принципиальна возможность горизонтального масштабирования с использованием недорогого «железа».
Иначе при характерном для нашего времени взрывном росте объемов данных можно быстро «слить» всю прибыль в увеличение серверных мощностей. Для небольших компаний принципиален фактор надежности и наличия облачных версий (managed service), когда заботу о работе СУБД, включая защиту персональных данных, DR (аварийное восстановление) и прочее, полностью берут на себя провайдеры.
- Если сформулировать главный тренд российского рынка СУБД одним тезисом, как бы вы его описали?
Российский рынок СУБД на сегодня — это рынок различных клонов Postgres. Как ни смотри, хоть в штуках, хоть в деньгах. И вряд ли что-то здесь изменится в ближайшем будущем, тем более что Postgres тоже не стоит на месте и развивается туда, куда ждут потребители, — в область поддержки ИИ (pgvector, например) или в сторону параллелизма вычислений. Если кто-то и бросает вызов, то в конкретных нишах — как, например, Lakehouse в аналитических задачах на больших объемах данных.
- Если сформулировать главный тренд российского рынка СУБД одним тезисом, как бы вы его описали?
Российский рынок СУБД на сегодня — это рынок различных клонов Postgres. Как ни смотри, хоть в штуках, хоть в деньгах. И вряд ли что-то здесь изменится в ближайшем будущем, тем более что Postgres тоже не стоит на месте и развивается туда, куда ждут потребители, — в область поддержки ИИ (pgvector, например) или в сторону параллелизма вычислений. Если кто-то и бросает вызов, то в конкретных нишах — как, например, Lakehouse в аналитических задачах на больших объемах данных.