Можно ли при импортозамещении поменять СУБД, не переписывая вместе с ней всё приложение?

Именно этот вопрос на INFOSTART TECH EVENT 2026 поднял Андрей Жуйков, Руководитель направления СУБД Digital Q.DataBase.
В своем выступлении он развеял главный миф импортозамещения: переход с Oracle или MS SQL Server не обязательно означает годы разработки, переписывание кода и остановку бизнес-процессов.

Мы на практике доказываем обратное.
Вот 5 ключевых отличий Digital Q.DataBase, которые меняют правила игры:

1. Совместимость, а не просто «база на PostgreSQL»

Мы поддерживаем диалекты T-SQL и PL/SQL «из коробки». Ваши существующие хранимые процедуры, функции, триггеры и даже пакеты Oracle (DBMS_, UTL_, OWA) исполняются без переделки. Приложение продолжает «думать», что работает с родной СУБД.

2. Миграция без остановки бизнеса

Вместо «большого взрыва» мы предлагаем контролируемый переход: встроенные инструменты переноса данных, автоматическая проверка результатов миграции и встроенный CDC (Change Data Capture) для непрерывной синхронизации. Даже корпоративная отчетность на базе RDL/SSRS продолжит работать.

3. Возможности за пределами классического PostgreSQL

Мы не просто форк, мы расширяем границы:
► In-memory компонента DGrid для сверхбыстрой аналитики;
► Персистентное Key-Value хранилище;
► Встроенные очереди сообщений (Publisher/Subscriber);
► Диагностика производительности в привычном для DBA стиле Oracle AWR/ASH.

4. Встроенный AI, а не сторонние «костыли»

Векторный поиск — это часть ядра. Нативный тип данных VECTOR, генерация эмбеддингов непосредственно из СУБД, поддержка индексов DiskANN и бесшовная интеграция как с внешними, так и с локальными LLM-моделями.

5. Прозрачная экономика

Стоимость владения Digital Q.DataBase ниже, чем у ряда других российских СУБД. Для старта и оценки возможностей доступна бесплатная версия с правом коммерческого использования.

Главный вывод доклада:

Поменять СУБД без переписывания приложения реально. Но только если выбрать платформу, которая говорит с вашим кодом на его родном языке.

Хотите увидеть, как это работает на практике?

► Вопросы по настройке и внедрению можно направлять на наш адрес службы поддержки: supportqdb@diasoft.ru

Рассказываем о пакетах, поддержанных в Digital Q.DataBase для совместимости с PL/SQL-окружением Oracle.
Сегодня — о пакете UTL_RECOMP.

Для чего он нужен

► Пакет UTL_RECOMP предназначен для перекомпиляции недействительных (invalid) объектов PL/SQL, представлений, Java-классов, индексов и операторов. Он особенно полезен после крупного обновления версии, когда все объекты становятся недействительными.

► Хотя недействительные объекты перекомпилируются автоматически при первом обращении, предварительный запуск UTL_RECOMP позволяет избежать задержек при выполнении операций в дальнейшем.

Основные возможности

· RECOMP_SERIAL — последовательная перекомпиляция недействительных объектов в указанной схеме или во всей базе данных;

· RECOMP_PARALLEL — параллельная перекомпиляция с использованием нескольких потоков. Количество потоков задаётся первым аргументом, если не указано — используется значение параметра job_queue_processes;

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

Пример использования

-- Последовательная перекомпиляция всех объектов в базе
EXEC UTL_RECOMP.RECOMP_SERIAL();

-- Перекомпиляция объектов в схеме SCOTT
EXEC UTL_RECOMP.RECOMP_SERIAL('SCOTT');

-- Параллельная перекомпиляция с 4 потоками
EXEC UTL_RECOMP.RECOMP_PARALLEL(4);

-- Перекомпиляция схемы JOE с числом потоков по умолчанию
EXEC UTL_RECOMP.RECOMP_PARALLEL(NULL, 'JOE');

Области применения

· Перекомпиляция объектов после миграции или крупного обновления;
· Восстановление работоспособности приложений после изменения схемы;
· Оптимизация производительности за счёт устранения недействительных объектов.

Сегодня 10 октября и это значит, что проекту "ВКонтакте" исполнилось 20 лет.

Для нас, людей из мира данных, эта дата интересна прежде всего инженерной стороной вопроса. VK начинался как студенческий проект одного всем известного человека — и писался с нуля: без сторонних библиотек и фреймворков, от личных сообщений до поиска.

И вот здесь начинается самое любопытное для DBA.

То, что начиналось как PHP-монолит на MySQL, сегодня — экосистема, которая пережила несколько волн переписывания архитектуры. Пик нагрузки VK — около 3 млн запросов в секунду, петабайты данных, сотни миллионов пользователей. Обычный MySQL с этим бы не справился — и не справился. Отсюда рост в сторону распределённых решений: шардирование, Galera Cluster для синхронной репликации, вынос аналитики в ClickHouse, переход на Go-сервисы и современные open-source СУБД.

Сейчас в стеке VK — PostgreSQL, MongoDB, Redis, Cassandra, ClickHouse, Kafka. Это уже не «сайт для студентов», а распределённая система, которая по сложности сопоставима с инфраструктурой любого глобального игрока.

Что полезного тут можно вынести для себя?

Пожалуй, одну простую мысль: любая система начинается с малого. MySQL в 2006-м казался достаточным. Через пять лет — перестал. Через десять — потребовалась собственная распределённая платформа.

Хороших Вам выходных, коллеги!

Расширение pg_when — человеческий способ записывать время

Сколько раз составляя SQL-запрос Вы мучались, высчитывая выражения дат и времени для критериев отбора? Расширение pg_when решает эту задачу элегантно: оно парсит естественный язык (к сожалению, только английский) и возвращает timestamptz (или Unix epoch в секундах, миллисекундах, микросекундах).

Запрос для функций из pg_when состоит из трёх компонентов — дата, время, часовой пояс — соединённых ключевыми словами at и in.

Несколько примеров:

-- Начало текущего часа, но 5 дней назад, в Москве
SELECT when_is('5 days ago at this hour in Europe/Moscow');

-- Следующая пятница, 20:00, в Москве
SELECT when_is('next friday at 20:00 in Europe/Moscow');

-- Ровно через 2 месяца, полночь, GMT+3
SELECT when_is('in 2 months at midnight in UTC+3');

-- Новогоднее выступление
SELECT when_is('31/12/2026 at 23:55');

-- Те же значения, но в Unix epoch
SELECT seconds_at('5 days ago at this hour in Europe/Moscow');
SELECT millis_at('5 days ago at this hour in Europe/Moscow');
SELECT micros_at('5 days ago at this hour in Europe/Moscow');

Поддерживаются относительные даты (today, yesterday, next week, last month, in 2 years), точные даты в разных форматах (YYYY-MM-DD, DD/MM/YYYY, 31-12-2026), время (midnight, evening, 20:00, 22:30) и именованные часовые пояса. Если часовой пояс не указан — используется UTC.

Расширение pg_when особенно полезно для создания запросов вида «покажи заказы за последнюю неделю» так, чтобы они работали каждый день без модификации их текста и при этом сохраняли «читаемость».

Рассказываем о пакетах, поддержанных в Digital Q.DataBase для совместимости с PL/SQL-окружением Oracle.
Сегодня — о пакете DBMS_XMLPARSER.

Для чего он нужен

► Пакет DBMS_XMLPARSER предоставляет интерфейс для чтения XML-документов и доступа к их содержимому и структуре . Он следует спецификации W3C XML и строит дерево разбора, доступное через DOM API .

Основные возможности

· newParser — создаёт новый экземпляр парсера ;
· parseBuffer / parseClob — разбирает XML из строки или CLOB ;
· parse — разбирает XML из файла или URL ;
· getDocument — возвращает DOM-документ после разбора ;
· freeParser — освобождает ресурсы парсера .

Пример использования

DECLARE
  myparser DBMS_XMLPARSER.parser;
  indomdoc DBMS_XMLDOM.DOMDocument;
  indoc    VARCHAR2(2000);
BEGIN
  indoc := '<emp><name>De Selby</name></emp>';
  myParser := DBMS_XMLPARSER.newParser;
  DBMS_XMLPARSER.parseBuffer(myParser, indoc);
  indomdoc := DBMS_XMLPARSER.getDocument(myParser);
  -- работа с DOM-документом
  DBMS_XMLPARSER.freeParser(myParser);
END;

Области применения

· Разбор входящих XML-сообщений без внешних парсеров;
· Построение DOM-дерева для последующей обработки;
· Интеграция с системами, обменивающимися XML-данными.

До второго Дня СУБД осталось всего 2 недели!

► Встречаемся уже 27 октября!
Если вы планируете миграцию с MS SQL или Oracle, хотите увидеть живые демо-стенды без необходимости переписывать код и лично пообщаться с командой разработки Digital Q.DataBase — это событие создано именно для вас!

Когда: 27 октября, 14:00–23:00 (МСК)
Где: Москва, Кибердом (м. «Улица 1905 года», 2-я Звенигородская ул., 12с18)

► И это не только про технологии: помимо насыщенной деловой программы, гостей ждут вкусный фуршет и отличная развлекательная программа!

► Вход свободный успейте забронировать место:
https://dbd.diasoft.ru

В Digital Q.DataBase реализован наш аналог Service Broker - встроенный механизм асинхронного обмена сообщениями между базами данных через очереди и диалоги.

Принцип работы:
отправитель → очередь сообщений → обработчик.

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

► Наш аналог Service Broker позволяет обмениваться сообщениями с Microsoft SQL Server в обоих направлениях, используя стандартные команды T-SQL.

В представленном примере Digital Q.DataBase находится слева, а Microsoft SQL Server 2022 - справа.

Сначала на обеих сторонах создаются службы командой CREATE SERVICE.
Каждая служба связывается с очередью сообщений.
Затем командой CREATE ROUTE настраивается маршрут доставки; в демонстрации проверяется адрес локального сервера localhost.

После настройки командой BEGIN DIALOG CONVERSATION открывается диалог.
Через SEND ON CONVERSATION из Digital Q.DataBase отправляется сообщение в Microsoft SQL Server.
На стороне SQL Server сообщение принимается, и проверяется его содержимое.

Затем Microsoft SQL Server отправляет ответ в рамках того же диалога.
На стороне Digital Q.DataBase ответное сообщение извлекается из очереди и читается.
Таким образом, демонстрация подтверждает успешный двусторонний обмен сообщениями между двумя СУБД.

► Для заказчика наш аналог Service Broker может быть полезен при постепенной (или даже полной) миграции приложений, использующих этот механизм.
Компоненты, работающие на Microsoft SQL Server и Digital Q.DataBase, могут продолжать обмениваться сообщениями при условии поддержки необходимых сценариев.

Схемы обмена сообщениями:

1. Очередь сообщений: отправитель → очередь → обработчик.

2. Publisher / Subscriber: одно событие доставляется нескольким подписчикам.

Расширяем набор пакетов, доступных в Digital Q.DataBase для тех, кто переходит с Oracle Database.
Сегодня — о пакете DBMS_AQ.

► Для чего он нужен

Пакет DBMS_AQ предоставляет интерфейс к механизму Oracle Advanced Queuing (AQ) — встроенной в СУБД системе обмена сообщениями.
Это позволяет приложениям обмениваться данными асинхронно, через очереди: один процесс помещает сообщение в очередь (enqueue), другой — извлекает его для обработки (dequeue).

►Основные возможности

· ENQUEUE — помещение сообщения в указанную очередь ;
· DEQUEUE — извлечение сообщения из очереди ;
· DEQUEUE_ARRAY — пакетное извлечение нескольких сообщений за один вызов ;
· LISTEN — прослушивание одной или нескольких очередей от имени агентов ;
· REGISTER — регистрация адреса электронной почты, PL/SQL-процедуры или HTTP-URL для уведомлений о поступлении сообщений ;
· Поддержка различных типов полезной нагрузки: RAW, объектные типы, XMLType.

Пример использования

-- Помещение сообщения в очередь
DECLARE
  enqueue_options     DBMS_AQ.ENQUEUE_OPTIONS_T;
  message_properties  DBMS_AQ.MESSAGE_PROPERTIES_T;
  message_id          RAW(16);
  payload             VARCHAR2(100) := 'Текст сообщения';
BEGIN
  DBMS_AQ.ENQUEUE(
    queue_name         => 'my_queue',
    enqueue_options    => enqueue_options,
    message_properties => message_properties,
    payload            => payload,
    msgid              => message_id);
  COMMIT;
END;

Области применения

· Асинхронный обмен данными между приложениями;
· Организация очередей задач для фоновой обработки;
· Интеграция с внешними системами через сообщения;
· Замена самописных механизмов очередей на встроенный в СУБД инструмент.

Поделюсь немного инсайдами о том, куда движется Digital Q.DataBase

Для начала напомню: в версии 18.2 мы разделили СУБД на три независимых модуля:

⚪Pearl — модуль PostgreSQL

🧊Marble — модуль, воспроизводящий функциональность Microsoft SQL Server

⚫Onyx — модуль, воспроизводящий функциональность Oracle Database

Каждый из них можно устанавливать, обновлять и сопровождать отдельно.
Если приложениям нужен только PostgreSQL, достаточно Pearl.

А теперь — о том, что впереди и что уже успели сделать.

В 🧊Marble скоро появится полнотекстовый поиск.

В ⚪Pearl готовимся к переходу на PostgreSQL 19.

В ⚫Onyx начали работу над прямым восстановлением дампов Oracle.
Без необходимости сначала разворачивать их в Oracle, а затем переносить базу в Onyx.
Это позволит убрать промежуточный этап миграции.

В нашем Digital Q.CDC (захвате изменения данных) уже появилась возможность репликации DDL и прав доступа.
То есть реплицировать можно не только изменения данных, но и изменения структуры базы и прав доступа.

Вот такие новости изнутри разработки.
Буду делиться подробностями по мере готовности!

🗓 36-я годовщина IMDb — Internet Movie Database

17 октября 1990 года Кол Нидхэм опубликовал в USENET-группе rec.arts.movies набор Unix shell-скриптов для поиска по спискам фильмов. Так родилась IMDb — на сегодня крупнейшая онлайн-база данных о кино, телевидении и видеоиграх.

И вот тут интересно рассмотреть как менялся техстек этого проекта:

В 1990 это были Unix shell-скрипты и текстовые файлы, а поиск выполнялся прямо из терминала ОС.

К 1995 это был уже сайт, контент стал доступнен через браузер. Внутреннее ПО было написано с нуля на Perl.

В 1998 проект IMDb покупает Amazon и в несколько итераций буквально перекраивает техстек.

Для начала они перенесли контент из файлов в БД под управлением MySQL. А позднее провели куда более мощные преобразования.

Сегодня «под капотом» у проекта IMDb гибридная архитектура на AWS:
• Amazon DynamoDB — NoSQL и key-value БД;
• Amazon Neptune — графовая БД для хранения связей между сущностями (knowledge graph);
• Amazon OpenSearch — полнотекстовый поиск;
• AWS Lambda + federated GraphQL — 19 субграфов (graphlets) и единый шлюз для клиентов (в IMDb данные для каждого уникального запроса параллельно извлекаются из 19 коллекций);
• Amazon S3 + CloudFront — хранение и раздача статики, предрасчитанных индексов и трейлеров.

И отдельно про «Магический поиск» (Magic Search): каждый, кто хоть раз пользовался IMDb отмечал, что она нереально быстро выдает информацию в ответ на Ваши запросы.

Результаты появляются мгновенно, пока Вы набираете запрос.

Как это работает?
Предположим, что Вы набрали «sta» и получили в ответ киноэпопею Star Wars, сериал Star Trek и актера Сильвестра Cталлоне. IMDb заранее рассчитала все осмысленные варианты, куда входит набранное Вами сочетание букв. Данные по каждому такому варианту сохранены в виде готовых документов. Комбинации, которые ни к чему не ведут (вроде stb), не сохраняются.

В результате поддерживаются в актуальном состоянии около 150 000 статических документов о фильмах и снявшихся в них актерах.

Готовые файлы с этим контентом лежат в Amazon S3 и раздаются через Amazon CloudFront (CDN от Amazon).

За счет использования CDN они физически близки к пользователю и отдача происходит намного быстрее, чем генерация любого динамического контента.

По сути, динамический поиск превратили в раздачу статики. Сервер ничего не генерирует в момент запроса — он просто отдаёт Вам через CDN заранее подготовленный файл. Это и обеспечивает ту самую «магическую» скорость работы под огромными ежедневными нагрузками.

В «кровавом enterprise» корпоративные архитекторы за такое бы руки вырвали любому, кто посмел бы такое предложить.

Но здесь во главу угла было поставлено не абстрактное «соответствие канонам», а практическая польза, стоимость запроса и впечатления пользователей от работы с порталом.

А потому IMDb живет и весьма шустро отвечает под нагрузкой более 200 миллионов запросов в день.

Еще раз поздравляем этот интересный с инженерной точки зрения проект с 36 годовщиной его существования.

Всем хороших выходных и отличного настроения!

Насколько Вы хороший DBA?

Представьте, что Вы полировали структуру БД, настраивали индексы.
А потом появляется расширение, которое без всякой вежливости выловит всё, что Вы могли сделать не так. Просто, жестко, с черным юмором.

Расширение pg_roast — это своего рода аудитор базы данных, который живёт прямо внутри PostgreSQL и проверяет схему, индексы, безопасность, конфигурацию и запросы.

Создатели расширения вдохновились книгой «PostgreSQL Mistakes and How to Avoid Them».

В отличие от всем известного расширения pganalyze, которое отвечает на вопрос «почему сейчас всё работает медленно?», pg_roast отвечает на вопрос «что неправильно в этой базе и режиме её использования?».

Причем описывает все найденные недочеты на человеческом языке — с сарказмом, но по делу. Идеально для code review или для аудита перед релизом.

Рискнете проверить свою БД?