В этом посте я бы хотел кратко рассказать, чем же отличаются Digital Q.DataBase и RuDB и какие задачи решает каждый из этих продуктов.
Digital Q.DataBase — коммерческая СУБД для корпоративных заказчиков. Одна из ключевых задач, которую она решает: как перейти с Oracle и Microsoft SQL Server, сохранив прикладную логику и минимизировав переписывание кода?
У Ассоциации разработчиков СУБД, которая развивает RuDB, другой исходный вопрос: зачем каждому российскому разработчику СУБД на базе PostgreSQL самостоятельно реализовывать одни и те же технологии?
У таких разработчиков много общих задач: безопасность, перенос данных, повышение производительности, совместимость с российскими приложениями.
Если каждую из них все решают отдельно, значительная часть усилий уходит на повторение одной и той же работы.
Идея ассоциации — объединить усилия в этой общей части.
Совместно развивать технологическую основу, на которой участники смогут создавать собственные продукты и конкурентные преимущества.
Здесь важно различать саму ассоциацию и RuDB. Ассоциация объединяет разработчиков, а RuDB — технологический результат их совместной работы.
Подробнее о возможностях RuDB можно прочитать на сайте database.ru.
А сейчас давайте разберём один конкретный пример — совместимость с функциональностью пакетов Oracle.
Представим корпоративное приложение, которое много лет работало на Oracle.
Внутри него есть такой фрагмент PL/SQL-кода, как на слайде (2).
Здесь используется пакет DBMS_AQ — механизм Oracle Advanced Queuing.
Приложение формирует сообщение и вызовом DBMS_AQ.ENQUEUE помещает его в очередь.
Теперь мы хотим перенести это приложение на обычный PostgreSQL.
В стандартной поставке PostgreSQL такого пакета нет.
И задача не сводится к тому, чтобы заменить название процедуры или поправить синтаксис.
За этим вызовом стоит определённое поведение: постановка сообщения в очередь, его последующая обработка, связь с транзакцией.
Разработчику нужно подобрать замену и проверить, что она обеспечивает необходимое приложению поведение.
Это может потребовать изменений в коде, а иногда — и в архитектуре.
Например, если принято решение использовать внешнюю систему обмена сообщениями.
Именно здесь становится понятна ценность таких наработок в RuDB.
В RuDB реализована функциональность работы с очередями, соответствующая этому примеру.
Вместо пакетного вызова DBMS_AQ.ENQUEUE используется функция dbms_aq_enqueue.
Но это не означает, что исходный PL/SQL-код можно перенести без изменений.
Код потребуется адаптировать, а работу с параметрами, типами данных и транзакциями — проверить.
При этом разработчику уже не нужно с нуля создавать сам механизм очереди.
Он может использовать готовую реализацию и сосредоточиться на адаптации приложения.
RuDB сокращает объём работы по воспроизведению необходимой функциональности при миграции.
Digital Q.DataBase идёт дальше в части совместимости с исходным приложением: задача продукта — сохранить не только нужную функциональность, но и исходный код там, где поддерживается соответствующая совместимость.
В примере на слайде (2) это означает сохранение привычного пакетного вызова из PL/SQL.
Таким образом, различие можно сформулировать так:
В RuDB мы используем готовую функциональность и адаптируем под неё код.
В Digital Q.DataBase мы стремимся сохранить и функциональность, и исходный код приложения.
Поэтому RuDB нельзя рассматривать просто как бесплатную версию Digital Q.DataBase.
У них разные задачи:
RuDB даёт разработчикам общую технологическую основу, а Digital Q.DataBase помогает корпоративным заказчикам переносить существующие приложения с минимальными изменениями.
#RuDB #QDB #СУБД #НовостиСУБД #Oracle #PLSQL #Импортозамещение
Digital Q.DataBase — коммерческая СУБД для корпоративных заказчиков. Одна из ключевых задач, которую она решает: как перейти с Oracle и Microsoft SQL Server, сохранив прикладную логику и минимизировав переписывание кода?
У Ассоциации разработчиков СУБД, которая развивает RuDB, другой исходный вопрос: зачем каждому российскому разработчику СУБД на базе PostgreSQL самостоятельно реализовывать одни и те же технологии?
У таких разработчиков много общих задач: безопасность, перенос данных, повышение производительности, совместимость с российскими приложениями.
Если каждую из них все решают отдельно, значительная часть усилий уходит на повторение одной и той же работы.
Идея ассоциации — объединить усилия в этой общей части.
Совместно развивать технологическую основу, на которой участники смогут создавать собственные продукты и конкурентные преимущества.
Здесь важно различать саму ассоциацию и RuDB. Ассоциация объединяет разработчиков, а RuDB — технологический результат их совместной работы.
Подробнее о возможностях RuDB можно прочитать на сайте database.ru.
А сейчас давайте разберём один конкретный пример — совместимость с функциональностью пакетов Oracle.
Представим корпоративное приложение, которое много лет работало на Oracle.
Внутри него есть такой фрагмент PL/SQL-кода, как на слайде (2).
Здесь используется пакет DBMS_AQ — механизм Oracle Advanced Queuing.
Приложение формирует сообщение и вызовом DBMS_AQ.ENQUEUE помещает его в очередь.
Теперь мы хотим перенести это приложение на обычный PostgreSQL.
В стандартной поставке PostgreSQL такого пакета нет.
И задача не сводится к тому, чтобы заменить название процедуры или поправить синтаксис.
За этим вызовом стоит определённое поведение: постановка сообщения в очередь, его последующая обработка, связь с транзакцией.
Разработчику нужно подобрать замену и проверить, что она обеспечивает необходимое приложению поведение.
Это может потребовать изменений в коде, а иногда — и в архитектуре.
Например, если принято решение использовать внешнюю систему обмена сообщениями.
Именно здесь становится понятна ценность таких наработок в RuDB.
В RuDB реализована функциональность работы с очередями, соответствующая этому примеру.
Вместо пакетного вызова DBMS_AQ.ENQUEUE используется функция dbms_aq_enqueue.
Но это не означает, что исходный PL/SQL-код можно перенести без изменений.
Код потребуется адаптировать, а работу с параметрами, типами данных и транзакциями — проверить.
При этом разработчику уже не нужно с нуля создавать сам механизм очереди.
Он может использовать готовую реализацию и сосредоточиться на адаптации приложения.
RuDB сокращает объём работы по воспроизведению необходимой функциональности при миграции.
Digital Q.DataBase идёт дальше в части совместимости с исходным приложением: задача продукта — сохранить не только нужную функциональность, но и исходный код там, где поддерживается соответствующая совместимость.
В примере на слайде (2) это означает сохранение привычного пакетного вызова из PL/SQL.
Таким образом, различие можно сформулировать так:
В RuDB мы используем готовую функциональность и адаптируем под неё код.
В Digital Q.DataBase мы стремимся сохранить и функциональность, и исходный код приложения.
Поэтому RuDB нельзя рассматривать просто как бесплатную версию Digital Q.DataBase.
У них разные задачи:
RuDB даёт разработчикам общую технологическую основу, а Digital Q.DataBase помогает корпоративным заказчикам переносить существующие приложения с минимальными изменениями.
#RuDB #QDB #СУБД #НовостиСУБД #Oracle #PLSQL #Импортозамещение
PostgreSQL 19: Beta 4 выйдет 24 сентября, SQL/PGQ исключили из релиза
Команда PostgreSQL объявила дату выхода четвёртой бета-версии PostgreSQL 19 — 24 сентября 2026 года.
Заморозка коммитов перед её выпуском запланирована на 19 сентября, 12:00 UTC.
Подготовка заняла больше времени из-за поступивших сообщений о проблемах.
Разработчики рассчитывают выпустить стабильную версию до конца октября, однако точная дата GA пока не утверждена.
Об этом говорится в анонсе от 3 сентября.
Одно из заметных изменений перед Beta 4 — удаление поддержки SQL/PGQ, предназначенной для запросов к графам свойств средствами SQL.
Среди нерешённых вопросов были работа GRAPH_TABLE с агрегатами и подзапросами, представление графов в системном каталоге и поддержка pg_dump.
В списке задач PostgreSQL 19 эти пункты закрыты откатом функциональности.
Для тех, кто планировал использовать SQL/PGQ, это означает, что рассчитывать на её появление в PostgreSQL 19 уже не стоит.
#PostgreSQL #PostgreSQL19 #СУБД #БазыДанных
Команда PostgreSQL объявила дату выхода четвёртой бета-версии PostgreSQL 19 — 24 сентября 2026 года.
Заморозка коммитов перед её выпуском запланирована на 19 сентября, 12:00 UTC.
Подготовка заняла больше времени из-за поступивших сообщений о проблемах.
Разработчики рассчитывают выпустить стабильную версию до конца октября, однако точная дата GA пока не утверждена.
Об этом говорится в анонсе от 3 сентября.
Одно из заметных изменений перед Beta 4 — удаление поддержки SQL/PGQ, предназначенной для запросов к графам свойств средствами SQL.
Среди нерешённых вопросов были работа GRAPH_TABLE с агрегатами и подзапросами, представление графов в системном каталоге и поддержка pg_dump.
В списке задач PostgreSQL 19 эти пункты закрыты откатом функциональности.
Для тех, кто планировал использовать SQL/PGQ, это означает, что рассчитывать на её появление в PostgreSQL 19 уже не стоит.
#PostgreSQL #PostgreSQL19 #СУБД #БазыДанных
«ЛИНТЕР БАСТИОН» и «ЛИНТЕР СОКОЛ» успешно прошли тестирование на совместимость с РОСА Хром 13.
Для компаний и госорганизаций это ещё одна проверенная комбинация СУБД и ОС — с меньшими рисками при переходе на российское ПО.
#ЛИНТЕР #СУБД #РОСА
Для компаний и госорганизаций это ещё одна проверенная комбинация СУБД и ОС — с меньшими рисками при переходе на российское ПО.
#ЛИНТЕР #СУБД #РОСА
День свободного ПО
Сегодня, 19 сентября, — Software Freedom Day. Праздник свободного ПО, который с 2006 года отмечают в третью субботу сентября.
Для нас эта дата особенно важна, ведь наша ассоциация работает над развитием российской СУБД RuDB. Это бесплатное ПО c открытыми исходными кодами, построенное на базе PostgreSQL, но существенно расширяющее его возможности для легких переходов с СУБД Oracle.
С праздником, коллеги! Пусть исходники будут открытыми, базы — живыми, а релизы — без блокеров. 🐘
#RuDB #PostgreSQL #OpenSource
Сегодня, 19 сентября, — Software Freedom Day. Праздник свободного ПО, который с 2006 года отмечают в третью субботу сентября.
Для нас эта дата особенно важна, ведь наша ассоциация работает над развитием российской СУБД RuDB. Это бесплатное ПО c открытыми исходными кодами, построенное на базе PostgreSQL, но существенно расширяющее его возможности для легких переходов с СУБД Oracle.
С праздником, коллеги! Пусть исходники будут открытыми, базы — живыми, а релизы — без блокеров. 🐘
#RuDB #PostgreSQL #OpenSource
OceanBase возглавила рынок распределённых транзакционных СУБД Азии и Океании
OceanBase заняла первое место по выручке за 2025 год с долей 15,5%.
Об этом компания сообщила 2 сентября, ссылаясь на исследование Omdia Distributed Transactional Database in Asia & Oceania - 2026.
Объём этого регионального рынка в 2025 году составил $902,4 млн.
По прогнозу Omdia, к 2029 году он достигнет $1,8 млрд при среднегодовом темпе роста 19,3%.
#OceanBase #НовостиСУБД #Omdia
OceanBase заняла первое место по выручке за 2025 год с долей 15,5%.
Об этом компания сообщила 2 сентября, ссылаясь на исследование Omdia Distributed Transactional Database in Asia & Oceania - 2026.
Объём этого регионального рынка в 2025 году составил $902,4 млн.
По прогнозу Omdia, к 2029 году он достигнет $1,8 млрд при среднегодовом темпе роста 19,3%.
#OceanBase #НовостиСУБД #Omdia
Из системы Innovaatik скачали персональные и медицинские данные пациентов в Эстонии
3 сентября стало известно о незаконном скачивании данных из системы Innovaatik - поставщика ПО для стоматологий.
По предварительной оценке полиции, инцидент затронул данные более 300 поставщиков медицинских услуг.
Число пострадавших пациентов устанавливается.
Среди скачанного - личные идентификационные коды, email-адреса и сведения о здоровье, преимущественно о стоматологическом лечении.
Данные также могли включать другую медицинскую историю.
Полиция задержала 45-летнего гражданина Эстонии.
По версии следствия, он получал незаконный доступ к базе с конца июня; компания обратилась в полицию в конце августа.
Публикация или передача данных третьим лицам не подтверждена.
На момент сообщения прокуратура считала, что широкое распространение, вероятно, удалось предотвратить.
Источник: ERR со ссылкой на полицию и прокуратуру.
Защищайте данные, господа. Пароль после утечки можно сменить, а историю болезни - нет.
#УтечкаДанных #Эстония #Innovaatik #СУБД
3 сентября стало известно о незаконном скачивании данных из системы Innovaatik - поставщика ПО для стоматологий.
По предварительной оценке полиции, инцидент затронул данные более 300 поставщиков медицинских услуг.
Число пострадавших пациентов устанавливается.
Среди скачанного - личные идентификационные коды, email-адреса и сведения о здоровье, преимущественно о стоматологическом лечении.
Данные также могли включать другую медицинскую историю.
Полиция задержала 45-летнего гражданина Эстонии.
По версии следствия, он получал незаконный доступ к базе с конца июня; компания обратилась в полицию в конце августа.
Публикация или передача данных третьим лицам не подтверждена.
На момент сообщения прокуратура считала, что широкое распространение, вероятно, удалось предотвратить.
Источник: ERR со ссылкой на полицию и прокуратуру.
Защищайте данные, господа. Пароль после утечки можно сменить, а историю болезни - нет.
#УтечкаДанных #Эстония #Innovaatik #СУБД
► Straits Research прогнозирует рост рынка графовых СУБД до $28,27 млрд к 2034 году
Мировой рынок графовых СУБД в 2025 году оценивался в $3,42 млрд, следует из отчёта Straits Research.
Компания прогнозирует увеличение его объёма до $28,27 млрд к 2034 году.
Заявленный среднегодовой темп роста (CAGR) на прогнозный период 2026–2034 годов составляет 26,45%.
Среди факторов роста аналитики называют развитие ИИ, графов знаний и спрос на анализ взаимосвязанных данных.
Источник: Straits Research
► Fortune Business Insights приводит более сдержанную оценку: $2,85 млрд за 2025 год и $20,29 млрд к 2034 году при CAGR 24,13% на период 2026–2034 годов.
Источник: Fortune Business Insights
Таким образом, обе компании ожидают быстрого расширения рынка, хотя их оценки его объёма различаются. Разница объясняется разными методологиями.
#АналитикаРынка #СУБД #StraitsResearch #FortuneBusinessInsights
Мировой рынок графовых СУБД в 2025 году оценивался в $3,42 млрд, следует из отчёта Straits Research.
Компания прогнозирует увеличение его объёма до $28,27 млрд к 2034 году.
Заявленный среднегодовой темп роста (CAGR) на прогнозный период 2026–2034 годов составляет 26,45%.
Среди факторов роста аналитики называют развитие ИИ, графов знаний и спрос на анализ взаимосвязанных данных.
Источник: Straits Research
► Fortune Business Insights приводит более сдержанную оценку: $2,85 млрд за 2025 год и $20,29 млрд к 2034 году при CAGR 24,13% на период 2026–2034 годов.
Источник: Fortune Business Insights
Таким образом, обе компании ожидают быстрого расширения рынка, хотя их оценки его объёма различаются. Разница объясняется разными методологиями.
#АналитикаРынка #СУБД #StraitsResearch #FortuneBusinessInsights
27 октября в Москве пройдет «День СУБД 2026»
«Диасофт» проводит второе крупное мероприятие, посвященное российскому рынку СУБД, миграции с зарубежных вендоров и практическому опыту эксплуатации отечественных систем.
Ключевая тема встречи - платформа Digital Q.DataBase.
Разработчики подробно расскажут о развитии экосистемы, инструментах бесшовной миграции и совместимости с PostgreSQL, Microsoft SQL Server и Oracle.
В программе:
► Живые демо миграции
► Выступления заказчиков
► Нетворкинг
► Практические чек-листы
► Фуршет и развлекательная программа
Место:
Московский Кибердом (м. «Улица 1905 года», 2-я Звенигородская ул., 12с18)
Время:
27 октября, 14:00–23:00 (МСК)
Участие бесплатное, необходима регистрация.
Подробности и регистрация:
https://dbd.diasoft.ru/
#DigitalQDataBase #СУБД #MSSQL #Oracle #PostgreSQL #Диасофт
«Диасофт» проводит второе крупное мероприятие, посвященное российскому рынку СУБД, миграции с зарубежных вендоров и практическому опыту эксплуатации отечественных систем.
Ключевая тема встречи - платформа Digital Q.DataBase.
Разработчики подробно расскажут о развитии экосистемы, инструментах бесшовной миграции и совместимости с PostgreSQL, Microsoft SQL Server и Oracle.
В программе:
► Живые демо миграции
► Выступления заказчиков
► Нетворкинг
► Практические чек-листы
► Фуршет и развлекательная программа
Место:
Московский Кибердом (м. «Улица 1905 года», 2-я Звенигородская ул., 12с18)
Время:
27 октября, 14:00–23:00 (МСК)
Участие бесплатное, необходима регистрация.
Подробности и регистрация:
https://dbd.diasoft.ru/
#DigitalQDataBase #СУБД #MSSQL #Oracle #PostgreSQL #Диасофт
15 сентября 2026 года группировка DataSuckers заявила о скачивании и уничтожении более 395 млн записей Tez Tour, связанных с бронированиями, заказами туров и финансовыми транзакциями. Хабр.
Компания подтвердила атаку на сайт и сообщила, что признаков утечки данных туристов и партнёров не выявлено.
По её данным, ERP-система не пострадала, действующие бронирования сохранились. Интерфакс.
По словам хакеров, атаке способствовало устаревшее ПО, а резервные копии удалось удалить, поскольку они хранились на одном сервере с сайтом.
► Очередной повод напомнить о базовых мерах: хранить бэкапы отдельно, проверять восстановление и защищать веб-сервисы от SQL-инъекций, небезопасной загрузки файлов.
#ЗащитаДанных #РезервноеКопирование #TezTour
Компания подтвердила атаку на сайт и сообщила, что признаков утечки данных туристов и партнёров не выявлено.
По её данным, ERP-система не пострадала, действующие бронирования сохранились. Интерфакс.
По словам хакеров, атаке способствовало устаревшее ПО, а резервные копии удалось удалить, поскольку они хранились на одном сервере с сайтом.
► Очередной повод напомнить о базовых мерах: хранить бэкапы отдельно, проверять восстановление и защищать веб-сервисы от SQL-инъекций, небезопасной загрузки файлов.
#ЗащитаДанных #РезервноеКопирование #TezTour
IDC: ИИ-агенты станут «третьим потребителем» данных и изменят рынок СУБД
Агентный ИИ, мультиоблачные стратегии и консолидация платформ будут стимулировать рост мирового рынка СУБД в 2026–2030 годах.
Такие факторы выделяет IDC в прогнозе, опубликованном 12 сентября 2026 года.
Исследование охватывает публичные облака и локальные развертывания, отдельные сегменты рынка и регионы.
Об этом говорится в открытом описании отчета IDC на MarketResearch.com
По оценке директора по исследованиям IDC Девина Пратта, развитие ИИ уже превратило выбор СУБД в вопрос для высшего руководства компаний.
Следующий этап потребует платформ, рассчитанных на работу множества агентов.
Преимущество, по мнению Пратта, получат поставщики, которые встроят в платформы управление данными, семантический контекст и автономные операции, обеспечив работу в мультиоблачных средах и инфраструктурах с требованиями к суверенитету данных.
Эти направления IDC связывает с лидерством на рынке до 2030 года. Описание прогноза IDC.
Для рынка СУБД это означает расширение требований к платформам: наряду с хранением и обработкой данных возрастает значение того, как агент понимает их смысл и в каких пределах может с ними работать.
#СУБД #БазыДанных #IDC #ИскусственныйИнтеллект #ИИагенты #УправлениеДанными
Агентный ИИ, мультиоблачные стратегии и консолидация платформ будут стимулировать рост мирового рынка СУБД в 2026–2030 годах.
Такие факторы выделяет IDC в прогнозе, опубликованном 12 сентября 2026 года.
Исследование охватывает публичные облака и локальные развертывания, отдельные сегменты рынка и регионы.
Об этом говорится в открытом описании отчета IDC на MarketResearch.com
По оценке директора по исследованиям IDC Девина Пратта, развитие ИИ уже превратило выбор СУБД в вопрос для высшего руководства компаний.
Следующий этап потребует платформ, рассчитанных на работу множества агентов.
Преимущество, по мнению Пратта, получат поставщики, которые встроят в платформы управление данными, семантический контекст и автономные операции, обеспечив работу в мультиоблачных средах и инфраструктурах с требованиями к суверенитету данных.
Эти направления IDC связывает с лидерством на рынке до 2030 года. Описание прогноза IDC.
Для рынка СУБД это означает расширение требований к платформам: наряду с хранением и обработкой данных возрастает значение того, как агент понимает их смысл и в каких пределах может с ними работать.
#СУБД #БазыДанных #IDC #ИскусственныйИнтеллект #ИИагенты #УправлениеДанными
Ждём 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