Ждём DuckDB 2.0 🦆
На подходе крупное обновление: по плану разработчиков, выход DuckDB 2.0 намечен на 21 октября.
Среди заявленных нововведений - серверный режим, триггеры, тип данных VARIANT, асинхронный ввод-вывод и новый SQL-парсер.
► Для тех, кому не терпится попробовать, уже доступна альфа-версия.
#DuckDB #СУБД #БазыДанных
На подходе крупное обновление: по плану разработчиков, выход DuckDB 2.0 намечен на 21 октября.
Среди заявленных нововведений - серверный режим, триггеры, тип данных VARIANT, асинхронный ввод-вывод и новый SQL-парсер.
► Для тех, кому не терпится попробовать, уже доступна альфа-версия.
#DuckDB #СУБД #БазыДанных
22 сентября 2026 года группировка ShinyHunters заявила о краже 2-3 ТБ данных действующих и бывших сотрудников ФБР, а также соискателей.
По версии злоумышленников, точкой входа стала ранее неизвестная zero-day уязвимость в Oracle PeopleSoft на рекрутинговом портале ведомства.
Об этом сообщил The Register.
ФБР подтвердило, что расследует заявления о несанкционированной активности на сайте FBIjobs.gov.
Помните о защите данных. Самые безопасные системы - это те, про которые никто не знает.
#НиДняБезВзломов #Кибербезопасность #ShinyHunters #ФБР
По версии злоумышленников, точкой входа стала ранее неизвестная zero-day уязвимость в Oracle PeopleSoft на рекрутинговом портале ведомства.
Об этом сообщил The Register.
ФБР подтвердило, что расследует заявления о несанкционированной активности на сайте FBIjobs.gov.
Помните о защите данных. Самые безопасные системы - это те, про которые никто не знает.
#НиДняБезВзломов #Кибербезопасность #ShinyHunters #ФБР
СУБД Neo4j 2026.09.0: ускорение векторного поиска и перезагрузка процедур без перезапуска.
21 сентября вышла новая версия графовой СУБД Neo4j, в которой улучшили производительность векторного поиска, добавили перезагрузку пользовательских процедур без перезапуска СУБД и расширили возможности Cypher 25.
По данным разработчиков, для векторного поиска с бинарным квантованием и повторной оценкой результатов задержка сократилась примерно в пять раз, а пропускная способность выросла в пять раз.
Улучшения затронули и скалярное квантование.
Чтобы получить полный эффект, индексы, созданные до версии 2026.08 и не обновляемые регулярно, рекомендуется пересоздать.
Новая процедура dbms.reloadProcedures() позволяет подгружать обновлённые пользовательские процедуры, функции и агрегатные функции без перезапуска СУБД.
Перезагрузку можно ограничить выбранным пространством имён.
Если она завершится ошибкой, ранее загруженные плагины продолжат работать.
В Cypher 25 появилась встроенная поддержка полнотекстового поиска через конструкцию SEARCH для простых шаблонов узлов и связей.
Также добавлены выражения для формирования словарей MAP на основе существующих словарей и списков.
Подробности — в официальных примечаниях к релизу
#Neo4j #ГрафовыеСУБД #ВекторныйПоиск #Cypher
21 сентября вышла новая версия графовой СУБД Neo4j, в которой улучшили производительность векторного поиска, добавили перезагрузку пользовательских процедур без перезапуска СУБД и расширили возможности Cypher 25.
По данным разработчиков, для векторного поиска с бинарным квантованием и повторной оценкой результатов задержка сократилась примерно в пять раз, а пропускная способность выросла в пять раз.
Улучшения затронули и скалярное квантование.
Чтобы получить полный эффект, индексы, созданные до версии 2026.08 и не обновляемые регулярно, рекомендуется пересоздать.
Новая процедура dbms.reloadProcedures() позволяет подгружать обновлённые пользовательские процедуры, функции и агрегатные функции без перезапуска СУБД.
Перезагрузку можно ограничить выбранным пространством имён.
Если она завершится ошибкой, ранее загруженные плагины продолжат работать.
В Cypher 25 появилась встроенная поддержка полнотекстового поиска через конструкцию SEARCH для простых шаблонов узлов и связей.
Также добавлены выражения для формирования словарей MAP на основе существующих словарей и списков.
Подробности — в официальных примечаниях к релизу
#Neo4j #ГрафовыеСУБД #ВекторныйПоиск #Cypher
Media is too big
VIEW IN TELEGRAM
День СУБД 2026. Сезон 2 уже близко!
Регистрируйтесь по ссылке:
https://dbd.diasoft.ru
А пока разогреваемся перед новым, вторым сезоном.
Максим Кутузов, коммерческий директор Диасофт, рассказывает, зачем рынку бесплатная открытая СУБД и как развивать её вместе.
В видео обсуждаем, почему разработчики тратят значительную часть ресурсов на одинаковые доработки и как объединение усилий помогает это изменить, что вошло в первую версию RuDB на PostgreSQL 18.2, включая доработки безопасности, in-memory-компоненту и аналоги функций пакетов Oracle.
А ещё разбираем, что открытый исходный код и бесплатное использование дают пользователям, как присоединиться к развитию RuDB и протестировать её на своих задачах.
Видео доступно на:
VK
Rutube
Dzen
YouTube
#ДеньСУБД #RuDB #АссоциацияРазработчиковСУБД
Регистрируйтесь по ссылке:
https://dbd.diasoft.ru
А пока разогреваемся перед новым, вторым сезоном.
Максим Кутузов, коммерческий директор Диасофт, рассказывает, зачем рынку бесплатная открытая СУБД и как развивать её вместе.
В видео обсуждаем, почему разработчики тратят значительную часть ресурсов на одинаковые доработки и как объединение усилий помогает это изменить, что вошло в первую версию RuDB на PostgreSQL 18.2, включая доработки безопасности, in-memory-компоненту и аналоги функций пакетов Oracle.
А ещё разбираем, что открытый исходный код и бесплатное использование дают пользователям, как присоединиться к развитию RuDB и протестировать её на своих задачах.
Видео доступно на:
VK
Rutube
Dzen
YouTube
#ДеньСУБД #RuDB #АссоциацияРазработчиковСУБД
Были опубликованы две статьи «VLDB 2026», международной конференции в области баз данных.
Исследователи из южнокорейского Университета Данкук под руководством профессора Чхве Чонму (Jongmoo Choi) разработали два подхода к повышению производительности хранилищ данных с помощью машинного обучения.
► Первая работа посвящена обучаемым индексам: модель изучает распределение ключей и помогает определить расположение данных.
Исследователи применили этот подход к хранилищу на основе LSM-дерева, чтобы повысить эффективность поиска и обработки данных.
Программа VLDB 2026
► Вторая разработка - S-RocksDB - использует обучение с подкреплением для управления потоком входящих записей.
Система анализирует состояние базы и заранее регулирует нагрузку, предупреждая остановки записи.
По сообщению университета, в экспериментах суммарное время таких остановок удалось сократить с примерно 50 секунд за минуту до менее одной секунды.
Именно к этому показателю относится заявленное улучшение до 50 раз.
Сообщение Университета Данкук
#БазыДанных #БольшиеДанные #RocksDB #VLDB2026
Исследователи из южнокорейского Университета Данкук под руководством профессора Чхве Чонму (Jongmoo Choi) разработали два подхода к повышению производительности хранилищ данных с помощью машинного обучения.
► Первая работа посвящена обучаемым индексам: модель изучает распределение ключей и помогает определить расположение данных.
Исследователи применили этот подход к хранилищу на основе LSM-дерева, чтобы повысить эффективность поиска и обработки данных.
Программа VLDB 2026
► Вторая разработка - S-RocksDB - использует обучение с подкреплением для управления потоком входящих записей.
Система анализирует состояние базы и заранее регулирует нагрузку, предупреждая остановки записи.
По сообщению университета, в экспериментах суммарное время таких остановок удалось сократить с примерно 50 секунд за минуту до менее одной секунды.
Именно к этому показателю относится заявленное улучшение до 50 раз.
Сообщение Университета Данкук
#БазыДанных #БольшиеДанные #RocksDB #VLDB2026
RuDB 26.09 официально доступен!
Эта версия завершает этап развития платформы на ядре PostgreSQL 18 и становится точкой перехода к следующему поколению — в следующем релизе RuDB будет построен уже на PostgreSQL 19.
Ключевые изменения в версии 26.09:
Векторный поиск и AI
► Функциональность pgvector встроена непосредственно в ядро RuDB. Добавлены типы vector, halfvec, sparsevec и индексные методы HNSW и IVFFlat.
► Реализован RUDB AI Vectorizer — механизм автоматической подготовки данных для семантического поиска (разбиение на фрагменты, асинхронная генерация эмбеддингов, интеграция с OpenAI, Voyage AI и Ollama).
Диагностика и мониторинг производительности
► Внедрена серверная инфраструктура ASH (Active Session History) и AWR (Automatic Workload Repository) для сбора и хранения диагностической информации об активных запросах.
► Добавлена поддержка DBMS_WORKLOAD_REPOSITORY: создание снапшотов, настройка периодов хранения и формирование AWR/ASH-отчетов в текстовом и HTML-форматах.
Расширение совместимости с Oracle API
► DBMS_BLOCKCHAIN_TABLE — реализованы blockchain-таблицы с формированием хеш-цепочек для контроля целостности данных.
► DBMS_SODA — добавлена поддержка Simple Oracle Document Access для работы с коллекциями и JSON-документами.
► DBMS_FGA — внедрена инфраструктура тонкого аудита (Fine-Grained Auditing).
► DBMS_METADATA — реализовано базовое получение DDL для основных типов объектов (TABLE, VIEW, INDEX, PROCEDURE и др.).
Прочие улучшения
► В системный каталог добавлены типы ROWID, UROWID и LONG.
► Расширены возможности аналога Oracle Web Toolkit (HTP/HTF/OWA) и пакета DBMS_JSON.
► Добавлены функции обработки сетевых имен и ACL в DBMS_NETWORK_ACL_UTILITY.
Скачать дистрибутив:
https://database.ru
#RuDB #СУБД #НовостиСУБД #Диасофт #АФТ #НППКТ
Эта версия завершает этап развития платформы на ядре PostgreSQL 18 и становится точкой перехода к следующему поколению — в следующем релизе RuDB будет построен уже на PostgreSQL 19.
Ключевые изменения в версии 26.09:
Векторный поиск и AI
► Функциональность pgvector встроена непосредственно в ядро RuDB. Добавлены типы vector, halfvec, sparsevec и индексные методы HNSW и IVFFlat.
► Реализован RUDB AI Vectorizer — механизм автоматической подготовки данных для семантического поиска (разбиение на фрагменты, асинхронная генерация эмбеддингов, интеграция с OpenAI, Voyage AI и Ollama).
Диагностика и мониторинг производительности
► Внедрена серверная инфраструктура ASH (Active Session History) и AWR (Automatic Workload Repository) для сбора и хранения диагностической информации об активных запросах.
► Добавлена поддержка DBMS_WORKLOAD_REPOSITORY: создание снапшотов, настройка периодов хранения и формирование AWR/ASH-отчетов в текстовом и HTML-форматах.
Расширение совместимости с Oracle API
► DBMS_BLOCKCHAIN_TABLE — реализованы blockchain-таблицы с формированием хеш-цепочек для контроля целостности данных.
► DBMS_SODA — добавлена поддержка Simple Oracle Document Access для работы с коллекциями и JSON-документами.
► DBMS_FGA — внедрена инфраструктура тонкого аудита (Fine-Grained Auditing).
► DBMS_METADATA — реализовано базовое получение DDL для основных типов объектов (TABLE, VIEW, INDEX, PROCEDURE и др.).
Прочие улучшения
► В системный каталог добавлены типы ROWID, UROWID и LONG.
► Расширены возможности аналога Oracle Web Toolkit (HTP/HTF/OWA) и пакета DBMS_JSON.
► Добавлены функции обработки сетевых имен и ACL в DBMS_NETWORK_ACL_UTILITY.
Скачать дистрибутив:
https://database.ru
#RuDB #СУБД #НовостиСУБД #Диасофт #АФТ #НППКТ
Небольшую LLM научили ускорять запросы PostgreSQL
Разработчик Рохан Бансал представил QORL - эксперимент по оптимизации SQL-запросов с помощью модели семейства Qwen на 4 млрд параметров.
После обучения на примерах и с подкреплением модель научилась подбирать подсказки для PostgreSQL через расширение pg_hint_plan.
По данным автора, на 113 запросах с множественными JOIN из Join Order Benchmark удалось получить ускорение в 1,81 раза по геометрическому среднему. Суммарное время выполнения нагрузки сократилось на 44,7%.
Есть существенная деталь: результат получен при трёх попытках поиска для каждого запроса и выборе лучшего варианта по замерам - из максимум 15 кандидатов. Если улучшение не находилось, сохранялся стандартный план PostgreSQL.
Это эксперимент для настройки повторяющихся аналитических запросов.
Цифра 1,81× не означает, что модель быстрее строит планы, и не учитывает полное время поиска и проверки кандидатов.
► Разбор автора
► Код проекта
#PostgreSQL #SQL #БазыДанных #LLM #ОптимизацияЗапросов
Разработчик Рохан Бансал представил QORL - эксперимент по оптимизации SQL-запросов с помощью модели семейства Qwen на 4 млрд параметров.
После обучения на примерах и с подкреплением модель научилась подбирать подсказки для PostgreSQL через расширение pg_hint_plan.
По данным автора, на 113 запросах с множественными JOIN из Join Order Benchmark удалось получить ускорение в 1,81 раза по геометрическому среднему. Суммарное время выполнения нагрузки сократилось на 44,7%.
Есть существенная деталь: результат получен при трёх попытках поиска для каждого запроса и выборе лучшего варианта по замерам - из максимум 15 кандидатов. Если улучшение не находилось, сохранялся стандартный план PostgreSQL.
Это эксперимент для настройки повторяющихся аналитических запросов.
Цифра 1,81× не означает, что модель быстрее строит планы, и не учитывает полное время поиска и проверки кандидатов.
► Разбор автора
► Код проекта
#PostgreSQL #SQL #БазыДанных #LLM #ОптимизацияЗапросов
«Посчитай отток клиентов» — звучит как задача на один запрос
Представим, что клиентские данные разбросаны по десяткам таблиц, рядом лежат старые выгрузки, а определение оттока ещё нужно уточнить.
Тут до первого SELECT предстоит немало работы.
Именно весь путь от потребности человека до полезного ответа рассматривают авторы Open Tabular Insight Extraction.
Они объединяют исследования поиска таблиц, text-to-SQL и аналитических агентов в общую рамку OpenTI.
Одна из главных претензий авторов к существующим тестам: входные запросы часто предполагают знание таблиц.
Такие тесты плохо отражают ситуацию, когда человек ещё не знает, где лежат нужные данные и как они устроены.
► Статья на arXiv
#arxiv #TextToSQL #AI #АнализДанных
Представим, что клиентские данные разбросаны по десяткам таблиц, рядом лежат старые выгрузки, а определение оттока ещё нужно уточнить.
Тут до первого SELECT предстоит немало работы.
Именно весь путь от потребности человека до полезного ответа рассматривают авторы Open Tabular Insight Extraction.
Они объединяют исследования поиска таблиц, text-to-SQL и аналитических агентов в общую рамку OpenTI.
Одна из главных претензий авторов к существующим тестам: входные запросы часто предполагают знание таблиц.
Такие тесты плохо отражают ситуацию, когда человек ещё не знает, где лежат нужные данные и как они устроены.
► Статья на arXiv
#arxiv #TextToSQL #AI #АнализДанных
Темы докладов EDB на PGConf.Asia 2026: PostgreSQL, ИИ и управление кластерами
EDB опубликовала обзор выступлений своих специалистов.
По данным компании, конференция пройдёт 17–18 ноября в Гонконге.
В программе — развитие PostgreSQL, поиск для ИИ-приложений, производительность и управление кластерами.
Брюс Момджян в ключевом докладе разберёт возможности, которых пока не хватает в ядре PostgreSQL:
подсказки оптимизатору, встроенный шардинг, прозрачное шифрование данных, глобальные индексы и мультимастерную репликацию.
Основной вопрос — что мешает их реализации.
В другом выступлении он рассмотрит, насколько успешно современные ИИ-модели генерируют SQL, используя MCP для работы с тестовой базой.
Отдельный доклад посвятят построению RAG на PostgreSQL: от загрузки и разбиения документов до хранения векторов с pgvector, гибридного поиска и передачи найденного контекста языковой модели.
Практическая часть охватит влияние структуры данных на расходы на инфраструктуру, блокировки при расширении таблиц и применение партиционирования для устранения узких мест.
Для тех, кто управляет кластерами, заявлены выступления о CloudNativePG в Kubernetes и автоматизации развёртывания через TPA.
Судя по анонсу, программа объединяет два направления: развитие PostgreSQL как основы для ИИ-приложений и решение повседневных задач эксплуатации — от производительности до высокой доступности.
#PostgreSQL #PGConfAsia #EDB #НовостиСУБД
EDB опубликовала обзор выступлений своих специалистов.
По данным компании, конференция пройдёт 17–18 ноября в Гонконге.
В программе — развитие PostgreSQL, поиск для ИИ-приложений, производительность и управление кластерами.
Брюс Момджян в ключевом докладе разберёт возможности, которых пока не хватает в ядре PostgreSQL:
подсказки оптимизатору, встроенный шардинг, прозрачное шифрование данных, глобальные индексы и мультимастерную репликацию.
Основной вопрос — что мешает их реализации.
В другом выступлении он рассмотрит, насколько успешно современные ИИ-модели генерируют SQL, используя MCP для работы с тестовой базой.
Отдельный доклад посвятят построению RAG на PostgreSQL: от загрузки и разбиения документов до хранения векторов с pgvector, гибридного поиска и передачи найденного контекста языковой модели.
Практическая часть охватит влияние структуры данных на расходы на инфраструктуру, блокировки при расширении таблиц и применение партиционирования для устранения узких мест.
Для тех, кто управляет кластерами, заявлены выступления о CloudNativePG в Kubernetes и автоматизации развёртывания через TPA.
Судя по анонсу, программа объединяет два направления: развитие PostgreSQL как основы для ИИ-приложений и решение повседневных задач эксплуатации — от производительности до высокой доступности.
#PostgreSQL #PGConfAsia #EDB #НовостиСУБД
Авторы DataKernelBench предложили десяти языковым моделям написать GPU-код для аналитических запросов.
SQL описывает, какие данные нужно получить.
За способом выполнения стоит целая последовательность действий: прочитать столбцы, отобрать строки, соединить таблицы, посчитать суммы.
GPU может выполнять много операций одновременно.
Однако одного переноса вычислений на видеокарту недостаточно: время уходит и на перемещение данных, и на создание промежуточных результатов.
Поэтому для конкретного запроса бывает выгодно написать собственное вычислительное ядро — небольшую программу, которую выполняет GPU.
DataKernelBench проверяет, насколько хорошо с такой работой справляются языковые модели.
Авторы переводят SQL в TorchPlan — программу на PyTorch, — а затем предлагают модели ускорить её с помощью CUDA или Triton, инструментов для программирования GPU.
Модели дают два варианта задачи: улучшить отдельный вычислительный участок или переработать выполнение запроса целиком.
Полученный код запускают, проверяют и возвращают модели обратную связь для исправлений.
Что показал эксперимент
Исследователи проверили десять моделей на аналитической нагрузке TPC-H SF10 с одной NVIDIA H100.
Лучший результат получила GPT-5.5 в режиме полной переработки запроса с CUDA: 2,11× относительно TorchPlan с torch.compile.
Все 22 запроса прошли проверку результата.
Это сравнение со скомпилированной реализацией на PyTorch.
Переносить цифру на PostgreSQL, ClickHouse или любую другую СУБД нельзя.
В эксперименте также участвовал GPU-движок Sirius: он оставался быстрее на многих отдельных запросах.
Такой подход может быть интересен для тяжёлых регулярных отчётов.
► Ссылка на исследование
#SQL #GPU #LLM #DataKernelBench #arxiv
SQL описывает, какие данные нужно получить.
За способом выполнения стоит целая последовательность действий: прочитать столбцы, отобрать строки, соединить таблицы, посчитать суммы.
GPU может выполнять много операций одновременно.
Однако одного переноса вычислений на видеокарту недостаточно: время уходит и на перемещение данных, и на создание промежуточных результатов.
Поэтому для конкретного запроса бывает выгодно написать собственное вычислительное ядро — небольшую программу, которую выполняет GPU.
DataKernelBench проверяет, насколько хорошо с такой работой справляются языковые модели.
Авторы переводят SQL в TorchPlan — программу на PyTorch, — а затем предлагают модели ускорить её с помощью CUDA или Triton, инструментов для программирования GPU.
Модели дают два варианта задачи: улучшить отдельный вычислительный участок или переработать выполнение запроса целиком.
Полученный код запускают, проверяют и возвращают модели обратную связь для исправлений.
Что показал эксперимент
Исследователи проверили десять моделей на аналитической нагрузке TPC-H SF10 с одной NVIDIA H100.
Лучший результат получила GPT-5.5 в режиме полной переработки запроса с CUDA: 2,11× относительно TorchPlan с torch.compile.
Все 22 запроса прошли проверку результата.
Это сравнение со скомпилированной реализацией на PyTorch.
Переносить цифру на PostgreSQL, ClickHouse или любую другую СУБД нельзя.
В эксперименте также участвовал GPU-движок Sirius: он оставался быстрее на многих отдельных запросах.
Такой подход может быть интересен для тяжёлых регулярных отчётов.
► Ссылка на исследование
#SQL #GPU #LLM #DataKernelBench #arxiv
«Додо Пицца»: 3,7 ТБ данных и 33 млрд записей
По данным «Коммерсанта», атакующие получили доступ примерно к 3,7 ТБ информации и 33 млрд записей, включая сведения о более чем 860 млн заказов за 15 лет.
Как пишет издание, входной точкой стали корпоративные учётные данные, опубликованные на GitHub.
Через связанные системы злоумышленники добрались до облачных хранилищ и баз данных.
Украденный архив выставили на продажу в даркнете.
Задержаны трое предполагаемых участников DataSuckers, четвёртый остаётся на свободе.
Мы уже неоднократно писали о DataSuckers и необходимости внимательно относиться к безопасности: на стороне атакующих работают профессионалы, хотя и они допускают ошибки.
По данным «Коммерсанта», одного из фигурантов вычислили по IP-адресу, который он раскрыл при обращении к похищенным данным..
#DataSuckers #ДодоПицца #БезопасностьБД
По данным «Коммерсанта», атакующие получили доступ примерно к 3,7 ТБ информации и 33 млрд записей, включая сведения о более чем 860 млн заказов за 15 лет.
Как пишет издание, входной точкой стали корпоративные учётные данные, опубликованные на GitHub.
Через связанные системы злоумышленники добрались до облачных хранилищ и баз данных.
Украденный архив выставили на продажу в даркнете.
Задержаны трое предполагаемых участников DataSuckers, четвёртый остаётся на свободе.
Мы уже неоднократно писали о DataSuckers и необходимости внимательно относиться к безопасности: на стороне атакующих работают профессионалы, хотя и они допускают ошибки.
По данным «Коммерсанта», одного из фигурантов вычислили по IP-адресу, который он раскрыл при обращении к похищенным данным..
#DataSuckers #ДодоПицца #БезопасностьБД
Первая волна импортозамещения стихает: российскому ПО предстоит конкурировать зрелостью
Российская софтверная индустрия переходит от быстрого заполнения освободившихся ниш к борьбе за эффективность внедрений.
Само наличие отечественного аналога становится менее убедительным аргументом для заказчика.
По данным ассоциации «Руссофт», совокупная выручка российских софтверных компаний по итогам 2025 года выросла на 14%, до 2,808 трлн рублей.
Годом ранее темп роста составлял 24%. Замедление сопровождалось снижением совокупной чистой прибыли и инвестиционной активности разработчиков.
Источник: «Руссофт».
В начале 2026 года ассоциация прогнозировала рост оборота отрасли лишь на 5–10%, связывая охлаждение спроса в том числе с исчерпанием первой волны импортозамещения. Более поздний опрос разработчиков дал оценку в 17%. Таким образом, речь идет о смене условий роста, а не об остановке рынка.
Февральская оценка, обновленный прогноз.
На возможности заказчиков влияют стоимость финансирования и общее охлаждение экономики.
Аналитики CNews также отмечают, что пик импортозамещения и связанный с ним всплеск инвестиций в цифровизацию остались позади.
Дальнейшую динамику они связывают, среди прочего, с переходом накопленных пилотных проектов к полноценным внедрениям.
Источник: CNews.
Для рынка СУБД этот переход ставит практический вопрос: насколько убедительно продукт подтверждает готовность к промышленной эксплуатации?
Совместимость с приложениями, стабильность под нагрузкой, инструменты миграции, качество поддержки и полная стоимость перехода становятся основой выбора.
Размер выручки вендора сам по себе не отвечает на эти вопросы.
При оценке конкретной СУБД заказчику нужны результаты испытаний, опыт сопоставимых внедрений и понятный план переноса данных с учетом допустимого простоя.
Первая волна импортозамещения открыла российским разработчикам доступ к новым заказчикам.
Следующий этап потребует доказать, что внедрение дает измеримый результат: снижает риски, обеспечивает необходимую производительность и позволяет развивать инфраструктуру.
#РоссийскоеПО #ИТрынок #СУБД #ТехнологическийСуверенитет #РазработкаПО
Российская софтверная индустрия переходит от быстрого заполнения освободившихся ниш к борьбе за эффективность внедрений.
Само наличие отечественного аналога становится менее убедительным аргументом для заказчика.
По данным ассоциации «Руссофт», совокупная выручка российских софтверных компаний по итогам 2025 года выросла на 14%, до 2,808 трлн рублей.
Годом ранее темп роста составлял 24%. Замедление сопровождалось снижением совокупной чистой прибыли и инвестиционной активности разработчиков.
Источник: «Руссофт».
В начале 2026 года ассоциация прогнозировала рост оборота отрасли лишь на 5–10%, связывая охлаждение спроса в том числе с исчерпанием первой волны импортозамещения. Более поздний опрос разработчиков дал оценку в 17%. Таким образом, речь идет о смене условий роста, а не об остановке рынка.
Февральская оценка, обновленный прогноз.
На возможности заказчиков влияют стоимость финансирования и общее охлаждение экономики.
Аналитики CNews также отмечают, что пик импортозамещения и связанный с ним всплеск инвестиций в цифровизацию остались позади.
Дальнейшую динамику они связывают, среди прочего, с переходом накопленных пилотных проектов к полноценным внедрениям.
Источник: CNews.
Для рынка СУБД этот переход ставит практический вопрос: насколько убедительно продукт подтверждает готовность к промышленной эксплуатации?
Совместимость с приложениями, стабильность под нагрузкой, инструменты миграции, качество поддержки и полная стоимость перехода становятся основой выбора.
Размер выручки вендора сам по себе не отвечает на эти вопросы.
При оценке конкретной СУБД заказчику нужны результаты испытаний, опыт сопоставимых внедрений и понятный план переноса данных с учетом допустимого простоя.
Первая волна импортозамещения открыла российским разработчикам доступ к новым заказчикам.
Следующий этап потребует доказать, что внедрение дает измеримый результат: снижает риски, обеспечивает необходимую производительность и позволяет развивать инфраструктуру.
#РоссийскоеПО #ИТрынок #СУБД #ТехнологическийСуверенитет #РазработкаПО