Хороший обзор, но было бы интересно рассмотреть установку и других компонентов: Центра Управления, CDC, Служб отчётов и др. Установка самых базовых пакетов это же только самый первый шаг. А продукт умеет намного больше, если установить дополнительные пакеты.
Скорее речь про прямое исполнение. У них три SQL-интерпретатора и каждый с полным стеком выполнения. Классический Постгрес и две реплики функциональности иностранных СУБД Oracle и MS SQL, созданные с помощью запчастей от Постгреса и других опенсорсных проектов с сильной долей собственных разработок. В общем, уже правильно говорить о наличии у Oracle и MS SQL их российских клонов. И если оракловый еще не полный, то клон MS SQL уже почти абсолютный. Настолько, что многие приложения его вообще не отличают от оригинала.
Для некоторых российских СУБД (например, для Postgres Pro и для Digital Q.DataBase) доля собственного, написанного в России кода уже в полтора-два раза больше, чем полный размер исходников ванильного PostgreSQL. Есть 5 известных российских СУБД, которые "якобы на базе PostgreSQL", но по факту уже очень далеко ушли от него и продолжают стремительно развиваться. В том же Digital Q.DataBase есть поддержка диалектов MS SQL и Oracle, а по количеству реализованных DBMS-пакетов эта СУБД уступает лишь самому Oracle и Tibero. Также есть прозрачное сжатие данных, интеллектуальное маскирование чувствительных данных и даже поиск информации по её смыслу на основе векторного поиска.
Спасибо Вам огромное за эту книгу. Издавая ее по каждой новой версии PostgreSQL, Вы делаете важное и полезное дело для всех, кто сейчас работает с этой СУБД!
Вы совершенно правы. Но миграция становится сложным и дорогим процессом тогда, когда исходная и целевая СУБД сильно отличаются по синтаксису и функциональным возможностям. И если представить, что найдется СУБД с тем же синтаксисом запросов и процедурного языка, то процесс идет сильно проще и обходится дешевле. Например, MySQL и MariaDB - переход с одной на другую обычно не вызывает проблем. Или, например, они же и Oceanbase, которая поддерживает синтаксис MySQL. Тут переход, конечно, посложнее, но зато и морковка послаще - горизонтальная масштабируемость на любое нужное количество узлов. Или наш российский пример: модуль Marble в Digital Q.DataBase буквально клонирует синтаксис и функциональность MS SQL. Иными словами, можно взять процедуру из MS SQL, скопировать "как есть" в их Marble и надеяться, что эта процедура будет там работать.
Может быть не самое популярное мнение выскажу, но пока количество российских СУБД на базе PostgreSQL (а их в реестре Минцифры 18) и даже полное количество российских СУБД (а их в реестре под 60) не привело к тому, что основная масса пользователей "трофейных" (как сейчас говорят) СУБД ушла бы на какую-то одну из них.
Уходят только те, кто обязан в силу закона, ЗОКИИ, госструктуры, банки и прочее. Частный бизнес не уходит. Сидит на своем любимом MS SQL или (кто покрупнее) на Oracle и не думает даже никуда уходить. В масштабах страны это многие тысячи инсталляций.
Посему у этих "желающих отсидеться" ни одна реестровая СУБД не смогла оказаться полноценной заменой для иностранных, почему сами и добровольно не переходят?
Мне кажется тут вопрос как раз в поведение вендоров упирается. Большинство российских СУБД платные. И я не про поддержку, а про лицензию. Причем стоят иной раз не меньше чем MS SQL на ту же конфигурацию, а то и дороже. А по функциональности лишь 3 (с натяжкой 5) сколь-нибудь значительно ушли от ваниллы в части функциональности, удобства администрирования и других эксплуатационных свойств. Плюс затраты на переписывание корпоративного ПО под Постгрес многим не по карману теперь. Вот и сидят на "трофейном".
Что радует, так это то, что хоть кто-то действительно сильно развивает свои СУБД. Обозначились уже лидеры и аутсайдеры.
Вангую, что еще пару-тройку лет и число оставшихся на рынке российских СУБД сильно сократится, многие десятки имен исчезнут (но этого никто не заметит ибо их и сейчас никто не знает, кроме тех кто по службе работает с Реестром российского ПО), некоторые новые вендоры появятся и уже эти новые и текущие уже сложившиеся лидеры и разделят рынок. Будет 4-6 продуктов, многие из которых и так уже на слуху, и всё.
По поводу самого курса куда развиваются российские СУБД - меня сильно смущают две вещи, отличающиеся от глобального (общемирового) тренда.
Игнорирование темы NewSQL серьезными вендорами (кроме YDB и недавно Сбера с заимствованным OceanBase, других и нет). А между тем потенциал вертикального масштабирования (наращивания числа ядер в сервере) себя уже исчерпал и уже всем понятно, что будущее за горизонтальным масштабированием. NewSQL-СУБД решают задачу горизонтального масштабирования на тысячи узлов, но сохраняют строгую (ACID) транзакционность. Текущий топ официального рейтинга результатов теста TPC-C как раз за такими решениями.
И также по поддержке векторизации тоже какой-то полный игнор, несмотря на крайнюю востребованность доя решения задач ИИ. Насколько я знаю только в Панголине, Digital Q.DataBase и RuDB есть возможность сформировать по тексту, аудиозаписи или графическому изображению эмбединги и потом вести поиск по сходству векторов. В то время как глобальные вендоры СУБД и китайцы уже давно считают эту функциональность рутинной.
Вполне возможно. Не попробовав на практике сложно предсказать результат. На вебинаре, где рассказывали про эту СУБД, говорили две интересные в этом плане вещи: 1. У них есть опыт перевода базы на 20 терабайт, причем за одни сутки; 2. Производительность может в определенных случаях даже улучшиться, так как Q.DataBase почти в 4 раза быстрее MS SQL в операциях вставки и обновления данных, в 2-3 раза медленнее его в мультиселектах и примерно сопоставим с ним на прочих операциях. В зависимости от того что именно делает код и как, он может как ускорится, так и замедлиться. Но в своих коммерческих проектах по переводу они юридически гарантируют, что производительность на том же оборудовании может снизиться не больше чем на 15%, а если будет замечено большая деградация, то они это исправят бесплатно, в рамках поддержки.
Если Вы про мой личный проект, о котором я Выше писал, то размер базы на "сейчас" 84 Гб, в самой большой по количеству записей таблице 71.8 миллиона записей, в самой большой по объему (11.2 Гб) таблице - 902 814 записей, но там большие бинарные данные хранятся. По современным меркам не так много, но учитывайте, что проекту уже 27 лет исполнилось - он можно сказать уже древний. Кстати, база прилично поджалась по занятому на диске пространству после переноса в Q.DataBase - только сейчас, собирая для Вас данные обнаружил, что её размер на диске стал на 19 Гб меньше, чем был в оригинале. При этом данные все на месте.
Главный прикол Q.DataBase, что она может исполнять хранимки и запросы MS SQL без их изменения, эмулирует системные таблицы и представления, позволяет исполнять CLR-сборки. В общем, полная иллюзия, что Вы продолжаете работать на MS SQL.
Если подключать к PostgreSQL внешний сервер MS SQL (через tds_fdw или похожие методы), то Вы запросы к данным пишите с оглядкой на PostgreSQL. И есть взаимодействие по сети со сторонним по отношению к PostgreSQL-серверу.
А тут получается, что все внутри. При этом можно еще и как обычный PostgreSQL использовать. Поведение этой СУБД зависит от того, через какой порт Вы к ней обращаетесь.
Зашли через 1433 - она прикидывается MS SQL, причем настолько, что с ней работают родные средства администрирования от Microsoft.
Зашли через 1521 - она изображает из себя Oracle.
Ну а если зашли по порту 5445, то ведет себя почти как обычный PostgreSQL.
"Почти" - потому что есть функции по работе с in-memory данными, потому что видны данные, занесенные через режимы эмуляции MS SQL и Oracle, можно вызывать хранимки, написанные на T-SQL или PL/SQL.
Не совсем понятно только зачем они порт по-умолчанию для PostgreSQL-диалекта поменяли. В PostgreSQL по-умолчанию порт 5432, у Q.DataBase 5445. Меня это несколько раздражает, каждый раз при подключении к ней как к PostgreSQL приходится указывать порт. Но порты при желании можно поменять в настройках.
Конфигурируется, кстати, как обычный PostgreSQL - postgresql.conf, pg_hba.conf и прочее в этом же духе.
Разумеется на основе личного опыта. Вот смотрите: у меня есть мой личный проект, которым я занимаюсь с 1998 года. Довольно сложный - 305K строк на PHP, еще почти 180K строк на Delphi, и 382К строк на T-SQL (хранимки). Ранее под него арендовался colocation физического сервера с Windows, потом VPS с Windows, сейчас он полностью переехал на Linux VPS, при этом не пришлось ничего менять ни в коде хранимок (они работают в Digital Q.DataBase без изменения текста), ни в коде на PHP (в нем по-прежнему запросы в синтаксисе MS SQL), а Delphi-код я руками перевел на Lasarus, но и в нем SQL-запросы я не менял.
У моих хороших знакомых есть своя компания. Сдают в аренду машины. У них использовалась своя собственная конфигурация для 1С, разработанная давно, приходящим программистом, связи с которым уже давно нет. Она слишком древняя, чтобы иметь хоть какие-то шансы быть переведенной на свежие версии платформы 1С. С моей помощью её за один день перетащили на бесплатную версию Digital Q.DataBase и она работает в полной уверенности, что продолжает работать с MS SQL.
У Диасофт есть примеры портации больших систем (причем не их собственных, а сторонних) с миллионами строк кода с MS SQL на их СУБД. Все эти истории вполне публичны, о них хорошие отзывы от тех, кто эти системы разрабатывал.
С заменой Oracle чуть сложнее - тут у меня своего личного опыта почти нет (я лишь попробовал те примеры, что идут в архиве с самой Q.DataBase - они у меня отработали нормально), но я знаю что всегда было большой проблемой при миграции с Oracle в PostgreSQL искать чем заменить обращения к DBMS_-пакетам. В Orafce есть только DBMS_OUTPUT и тот работает не совсем так как в Оракле. А Диасофт заявляет о поддержке десятков самых популярных DBMS_-и UTL_-пакетов, да еще и предлагает другими разработчикам СУБД на базе Постгреса воспользоваться этими результатами, причем совершенно бесплатно.
Я не призываю немедленно ставить везде вместо PostgreSQL эту СУБД, но очень рекомендую хотя бы попробовать её. Она бесплатная, если на сервере или в VM менее 8 ядер. Скачиваете с их сайта архив, ставите из него два deb или rpm (в зависимости от дистрибутива Linux) пакета и система готова к работе. А если сидите на Windows, то через форму обратной связи можно попросить образ докер-контейнера с предустановленной СУБД и инсталляционный комплект с их клиентскими утилитами под Винду.
Очень многие вещи с MS SQL на Q.DataBase работают как на оригинальном MS SQL вообще без изменения хоть чего-либо в теле процедур или тексте запросов.
Диасофт обещает, что за несколько лет скопирует в своей СУБД 100% всего того, что есть в MS SQL и Oracle, а на последнем партнерском дне пообещали, что добавят в свой Полиглот и другие SQL-диалекты.
В общем, смотрите сами, но мне кажется это стоит хотя бы раз увидеть своими глазами/пощупать руками, чтобы понять что это как минимум интересно и весьма оригинально.
Попробую поделиться своим видением на тему почему есть смысл использовать Q.DataBase вместо ванильного PostgreSQL:
И то и другое можно использовать бесплатно, они полностью совместимы в части возможностей опенсорсного PostgreSQL, но в Q.DataBase есть ряд интересных фишек, что нет в ванильной версии: векторный поиск, например. Или встроенная in-memory, доступ к которой есть прямо из SQL. Или куча фишек из Oracle / MS SQL, что сильно облегчают перенос прикладной логики с этих систем (например, те же DBMS_- и UTL_-пакеты).
К Q.DataBase можно прикупить (если нужно) саппорт и он реально очень сильно помогает в вопросах переноса функциональности с Oracle или Microsoft SQL Server на эту СУБД.
Q.DataBase "может прикинуться" MS SQL и к нему могут подключиться сторонние приложения, "считая" что работают с оригинальным MS SQL. В принципе нечто подобное заявлено и для Oracle, но там есть нюансы, в отличие от MS SQL.
Можно использовать для изучения синтаксиса PL/SQL и T-SQL не имея доступа (в последнее время с этим сложно) к оригинальным Oracle и MS SQL.
Частные лица могут поставить эту штуку на персональный VPS/VDS и использовать как четыре разных СУБД для нужд своих проектов (существенная экономия ресурсов сервера, да и не поставить сейчас нигде легально MS SQL на VPS).
Небольшим компаниям и ИП может быть интересно то, что на этой СУБД могут работать различные конфигурации 1С, например даже те, что сделаны под версии, где еще не было поддержки работы на PostgreSQL. В этом случае они будут работать с Q.DataBase через его режим совместимости с MS SQL.
Крупному бизнесу может понравиться то, что перейти на эту СУБД c MS SQL или Oracle в разы легче, чем с них же на ванильный Постгрес или любой другой его форк. В Q.DataBase есть аналоги почти для всех популярных DBMS-пакетов. Не надо мучительно думать чем заменить в коде хранимки условный DBMS_DESCRIBE, DBMS_XMLDOM, DBMS_AQ, UTL_MAIL или UTL_COMPRESS. Опять же есть сертификат ФСТЭК, запись в реестре российского ПО и прочее, что сейчас часто требуется в контексте импортозамещения.
Так что переход с PostgreSQL это в основном про ванильные версии. Но можно им воспользоваться и для перехода с коммерческих форков.
Хороший обзор, но было бы интересно рассмотреть установку и других компонентов: Центра Управления, CDC, Служб отчётов и др. Установка самых базовых пакетов это же только самый первый шаг. А продукт умеет намного больше, если установить дополнительные пакеты.
Скорее речь про прямое исполнение. У них три SQL-интерпретатора и каждый с полным стеком выполнения. Классический Постгрес и две реплики функциональности иностранных СУБД Oracle и MS SQL, созданные с помощью запчастей от Постгреса и других опенсорсных проектов с сильной долей собственных разработок. В общем, уже правильно говорить о наличии у Oracle и MS SQL их российских клонов. И если оракловый еще не полный, то клон MS SQL уже почти абсолютный. Настолько, что многие приложения его вообще не отличают от оригинала.
Для некоторых российских СУБД (например, для Postgres Pro и для Digital Q.DataBase) доля собственного, написанного в России кода уже в полтора-два раза больше, чем полный размер исходников ванильного PostgreSQL. Есть 5 известных российских СУБД, которые "якобы на базе PostgreSQL", но по факту уже очень далеко ушли от него и продолжают стремительно развиваться. В том же Digital Q.DataBase есть поддержка диалектов MS SQL и Oracle, а по количеству реализованных DBMS-пакетов эта СУБД уступает лишь самому Oracle и Tibero. Также есть прозрачное сжатие данных, интеллектуальное маскирование чувствительных данных и даже поиск информации по её смыслу на основе векторного поиска.
Спасибо Вам огромное за эту книгу. Издавая ее по каждой новой версии PostgreSQL, Вы делаете важное и полезное дело для всех, кто сейчас работает с этой СУБД!
Вы совершенно правы. Но миграция становится сложным и дорогим процессом тогда, когда исходная и целевая СУБД сильно отличаются по синтаксису и функциональным возможностям. И если представить, что найдется СУБД с тем же синтаксисом запросов и процедурного языка, то процесс идет сильно проще и обходится дешевле. Например, MySQL и MariaDB - переход с одной на другую обычно не вызывает проблем. Или, например, они же и Oceanbase, которая поддерживает синтаксис MySQL. Тут переход, конечно, посложнее, но зато и морковка послаще - горизонтальная масштабируемость на любое нужное количество узлов. Или наш российский пример: модуль Marble в Digital Q.DataBase буквально клонирует синтаксис и функциональность MS SQL. Иными словами, можно взять процедуру из MS SQL, скопировать "как есть" в их Marble и надеяться, что эта процедура будет там работать.
Может быть не самое популярное мнение выскажу, но пока количество российских СУБД на базе PostgreSQL (а их в реестре Минцифры 18) и даже полное количество российских СУБД (а их в реестре под 60) не привело к тому, что основная масса пользователей "трофейных" (как сейчас говорят) СУБД ушла бы на какую-то одну из них.
Уходят только те, кто обязан в силу закона, ЗОКИИ, госструктуры, банки и прочее. Частный бизнес не уходит. Сидит на своем любимом MS SQL или (кто покрупнее) на Oracle и не думает даже никуда уходить. В масштабах страны это многие тысячи инсталляций.
Посему у этих "желающих отсидеться" ни одна реестровая СУБД не смогла оказаться полноценной заменой для иностранных, почему сами и добровольно не переходят?
Мне кажется тут вопрос как раз в поведение вендоров упирается. Большинство российских СУБД платные. И я не про поддержку, а про лицензию. Причем стоят иной раз не меньше чем MS SQL на ту же конфигурацию, а то и дороже. А по функциональности лишь 3 (с натяжкой 5) сколь-нибудь значительно ушли от ваниллы в части функциональности, удобства администрирования и других эксплуатационных свойств. Плюс затраты на переписывание корпоративного ПО под Постгрес многим не по карману теперь. Вот и сидят на "трофейном".
Что радует, так это то, что хоть кто-то действительно сильно развивает свои СУБД. Обозначились уже лидеры и аутсайдеры.
Вангую, что еще пару-тройку лет и число оставшихся на рынке российских СУБД сильно сократится, многие десятки имен исчезнут (но этого никто не заметит ибо их и сейчас никто не знает, кроме тех кто по службе работает с Реестром российского ПО), некоторые новые вендоры появятся и уже эти новые и текущие уже сложившиеся лидеры и разделят рынок. Будет 4-6 продуктов, многие из которых и так уже на слуху, и всё.
По поводу самого курса куда развиваются российские СУБД - меня сильно смущают две вещи, отличающиеся от глобального (общемирового) тренда.
Игнорирование темы NewSQL серьезными вендорами (кроме YDB и недавно Сбера с заимствованным OceanBase, других и нет). А между тем потенциал вертикального масштабирования (наращивания числа ядер в сервере) себя уже исчерпал и уже всем понятно, что будущее за горизонтальным масштабированием. NewSQL-СУБД решают задачу горизонтального масштабирования на тысячи узлов, но сохраняют строгую (ACID) транзакционность. Текущий топ официального рейтинга результатов теста TPC-C как раз за такими решениями.
И также по поддержке векторизации тоже какой-то полный игнор, несмотря на крайнюю востребованность доя решения задач ИИ. Насколько я знаю только в Панголине, Digital Q.DataBase и RuDB есть возможность сформировать по тексту, аудиозаписи или графическому изображению эмбединги и потом вести поиск по сходству векторов. В то время как глобальные вендоры СУБД и китайцы уже давно считают эту функциональность рутинной.
Да, это будут три инсталляции продукта. Правда каждая не в полной конфигурации. Но нет никаких проблем ставить модули на одну ВМ/в один контейнер.
Вполне возможно. Не попробовав на практике сложно предсказать результат. На вебинаре, где рассказывали про эту СУБД, говорили две интересные в этом плане вещи: 1. У них есть опыт перевода базы на 20 терабайт, причем за одни сутки; 2. Производительность может в определенных случаях даже улучшиться, так как Q.DataBase почти в 4 раза быстрее MS SQL в операциях вставки и обновления данных, в 2-3 раза медленнее его в мультиселектах и примерно сопоставим с ним на прочих операциях. В зависимости от того что именно делает код и как, он может как ускорится, так и замедлиться. Но в своих коммерческих проектах по переводу они юридически гарантируют, что производительность на том же оборудовании может снизиться не больше чем на 15%, а если будет замечено большая деградация, то они это исправят бесплатно, в рамках поддержки.
Если Вы про мой личный проект, о котором я Выше писал, то размер базы на "сейчас" 84 Гб, в самой большой по количеству записей таблице 71.8 миллиона записей, в самой большой по объему (11.2 Гб) таблице - 902 814 записей, но там большие бинарные данные хранятся. По современным меркам не так много, но учитывайте, что проекту уже 27 лет исполнилось - он можно сказать уже древний. Кстати, база прилично поджалась по занятому на диске пространству после переноса в Q.DataBase - только сейчас, собирая для Вас данные обнаружил, что её размер на диске стал на 19 Гб меньше, чем был в оригинале. При этом данные все на месте.
Главный прикол Q.DataBase, что она может исполнять хранимки и запросы MS SQL без их изменения, эмулирует системные таблицы и представления, позволяет исполнять CLR-сборки. В общем, полная иллюзия, что Вы продолжаете работать на MS SQL.
Если подключать к PostgreSQL внешний сервер MS SQL (через tds_fdw или похожие методы), то Вы запросы к данным пишите с оглядкой на PostgreSQL. И есть взаимодействие по сети со сторонним по отношению к PostgreSQL-серверу.
А тут получается, что все внутри. При этом можно еще и как обычный PostgreSQL использовать. Поведение этой СУБД зависит от того, через какой порт Вы к ней обращаетесь.
Зашли через 1433 - она прикидывается MS SQL, причем настолько, что с ней работают родные средства администрирования от Microsoft.
Зашли через 1521 - она изображает из себя Oracle.
Ну а если зашли по порту 5445, то ведет себя почти как обычный PostgreSQL.
"Почти" - потому что есть функции по работе с in-memory данными, потому что видны данные, занесенные через режимы эмуляции MS SQL и Oracle, можно вызывать хранимки, написанные на T-SQL или PL/SQL.
Не совсем понятно только зачем они порт по-умолчанию для PostgreSQL-диалекта поменяли. В PostgreSQL по-умолчанию порт 5432, у Q.DataBase 5445. Меня это несколько раздражает, каждый раз при подключении к ней как к PostgreSQL приходится указывать порт. Но порты при желании можно поменять в настройках.
Конфигурируется, кстати, как обычный PostgreSQL - postgresql.conf, pg_hba.conf и прочее в этом же духе.
Разумеется на основе личного опыта. Вот смотрите: у меня есть мой личный проект, которым я занимаюсь с 1998 года. Довольно сложный - 305K строк на PHP, еще почти 180K строк на Delphi, и 382К строк на T-SQL (хранимки). Ранее под него арендовался colocation физического сервера с Windows, потом VPS с Windows, сейчас он полностью переехал на Linux VPS, при этом не пришлось ничего менять ни в коде хранимок (они работают в Digital Q.DataBase без изменения текста), ни в коде на PHP (в нем по-прежнему запросы в синтаксисе MS SQL), а Delphi-код я руками перевел на Lasarus, но и в нем SQL-запросы я не менял.
У моих хороших знакомых есть своя компания. Сдают в аренду машины. У них использовалась своя собственная конфигурация для 1С, разработанная давно, приходящим программистом, связи с которым уже давно нет. Она слишком древняя, чтобы иметь хоть какие-то шансы быть переведенной на свежие версии платформы 1С. С моей помощью её за один день перетащили на бесплатную версию Digital Q.DataBase и она работает в полной уверенности, что продолжает работать с MS SQL.
У Диасофт есть примеры портации больших систем (причем не их собственных, а сторонних) с миллионами строк кода с MS SQL на их СУБД. Все эти истории вполне публичны, о них хорошие отзывы от тех, кто эти системы разрабатывал.
С заменой Oracle чуть сложнее - тут у меня своего личного опыта почти нет (я лишь попробовал те примеры, что идут в архиве с самой Q.DataBase - они у меня отработали нормально), но я знаю что всегда было большой проблемой при миграции с Oracle в PostgreSQL искать чем заменить обращения к DBMS_-пакетам. В Orafce есть только DBMS_OUTPUT и тот работает не совсем так как в Оракле. А Диасофт заявляет о поддержке десятков самых популярных DBMS_-и UTL_-пакетов, да еще и предлагает другими разработчикам СУБД на базе Постгреса воспользоваться этими результатами, причем совершенно бесплатно.
Я не призываю немедленно ставить везде вместо PostgreSQL эту СУБД, но очень рекомендую хотя бы попробовать её. Она бесплатная, если на сервере или в VM менее 8 ядер. Скачиваете с их сайта архив, ставите из него два deb или rpm (в зависимости от дистрибутива Linux) пакета и система готова к работе. А если сидите на Windows, то через форму обратной связи можно попросить образ докер-контейнера с предустановленной СУБД и инсталляционный комплект с их клиентскими утилитами под Винду.
Очень многие вещи с MS SQL на Q.DataBase работают как на оригинальном MS SQL вообще без изменения хоть чего-либо в теле процедур или тексте запросов.
Диасофт обещает, что за несколько лет скопирует в своей СУБД 100% всего того, что есть в MS SQL и Oracle, а на последнем партнерском дне пообещали, что добавят в свой Полиглот и другие SQL-диалекты.
В общем, смотрите сами, но мне кажется это стоит хотя бы раз увидеть своими глазами/пощупать руками, чтобы понять что это как минимум интересно и весьма оригинально.
Попробую поделиться своим видением на тему почему есть смысл использовать Q.DataBase вместо ванильного PostgreSQL:
И то и другое можно использовать бесплатно, они полностью совместимы в части возможностей опенсорсного PostgreSQL, но в Q.DataBase есть ряд интересных фишек, что нет в ванильной версии: векторный поиск, например. Или встроенная in-memory, доступ к которой есть прямо из SQL. Или куча фишек из Oracle / MS SQL, что сильно облегчают перенос прикладной логики с этих систем (например, те же DBMS_- и UTL_-пакеты).
К Q.DataBase можно прикупить (если нужно) саппорт и он реально очень сильно помогает в вопросах переноса функциональности с Oracle или Microsoft SQL Server на эту СУБД.
Q.DataBase "может прикинуться" MS SQL и к нему могут подключиться сторонние приложения, "считая" что работают с оригинальным MS SQL. В принципе нечто подобное заявлено и для Oracle, но там есть нюансы, в отличие от MS SQL.
Можно использовать для изучения синтаксиса PL/SQL и T-SQL не имея доступа (в последнее время с этим сложно) к оригинальным Oracle и MS SQL.
Частные лица могут поставить эту штуку на персональный VPS/VDS и использовать как четыре разных СУБД для нужд своих проектов (существенная экономия ресурсов сервера, да и не поставить сейчас нигде легально MS SQL на VPS).
Небольшим компаниям и ИП может быть интересно то, что на этой СУБД могут работать различные конфигурации 1С, например даже те, что сделаны под версии, где еще не было поддержки работы на PostgreSQL. В этом случае они будут работать с Q.DataBase через его режим совместимости с MS SQL.
Крупному бизнесу может понравиться то, что перейти на эту СУБД c MS SQL или Oracle в разы легче, чем с них же на ванильный Постгрес или любой другой его форк. В Q.DataBase есть аналоги почти для всех популярных DBMS-пакетов. Не надо мучительно думать чем заменить в коде хранимки условный DBMS_DESCRIBE, DBMS_XMLDOM, DBMS_AQ, UTL_MAIL или UTL_COMPRESS. Опять же есть сертификат ФСТЭК, запись в реестре российского ПО и прочее, что сейчас часто требуется в контексте импортозамещения.
Так что переход с PostgreSQL это в основном про ванильные версии. Но можно им воспользоваться и для перехода с коммерческих форков.