10 августа я провёл вебинар, посвящённый новым возможностям Digital Q.DataBase 18.2 - СУБД + AI в Digital Q.DataBase
В программе:
🔹 Развитие полиглотной платформы единая платформа для PostgreSQL, Microsoft SQL Server и Oracle; новые возможности совместимости; 🔹 Новые возможности RuDB новые пакеты; развитие функциональности; 🔹 ИИ и векторный поиск поддержка векторных операций; 🔹 KV-хранилище DGrid развитие встроенного KV-хранилища; архитектура решения;
► Бесплатная полнофункциональная версия дистрибутива (до 8 ядер) с возможностью использования в том числе в коммерческих целях.
► С 1 сентября 2026 года компания «Диасофт» переходит на новую лицензионную политику СУБД Digital Q.DataBase (до 4-х ядер).
Как redb хранит сложные объекты: не бесхемная свалка, а RTTI
Про redb (RedBase) есть два зеркальных заблуждения. Первое: раз объект пишется «как документ», внутри лежит сериализованный JSON или блоб. Второе, противоположное: раз всё падает в общую таблицу значений — значит это плоский мешок пар «ключ-значение» без схемы.
Оба мимо. То, что внутри — это RTTI, полноценная система типов, живущая в самой базе. И устроена она заметно сложнее, чем и блоб, и «атрибут-значение». Разбор архитектуры я подробно давал в отдельной статье на Хабре: «redb: реляционное хранилище объектов» — ниже сжатая суть.
Слой типов: база знает настоящий тип каждого поля
redb хранит не только данные, но и их описание типов — три связанных уровня:
types — реальные дескрипторы типов (db_type и соответствие .NET-типу);
_schemes — сами типы (классы), с поддержкой наследования через self-reference;
structures — типизированные поля схемы: имя (name), тип (_id_type, FK на types), признак коллекции (collection_type) и вложенность (_id_parent).
Значения в values всегда привязаны к конкретной структуре (id_structure, FK на structures). Поэтому строка values — это не безымянная пара «атрибут-значение»: это значение известного, именованного, типизированного, возможно вложенного поля известного класса. База в рантайме знает, что перед ней — decimal Salary в схеме Employee, а не абстрактный «атрибут №42». Это и есть RTTI.
Хранение коллекций: построчно, реляционно
Вложенные массивы, словари и глубокие иерархии redb раскладывает в _values построчно, а не строкой:
Никаких JSON-блобов на диске. Каждый элемент коллекции — отдельная строка с типизированными колонками (_value_long, valuestring, valuedatetime, valueguid, …), внешними ключами и обычными индексами.
Связь и порядок — реляционные. Вложенность собирается self-reference колонкой arrayparent_id (FK на values.id, ON DELETE CASCADE). Порядок массива и ключи словаря — в arrayindex (text: '0','1','2' для массивов, строковый ключ — для словарей).
Один элемент — одна строка.List<OrderItem> внутри класса не превращается ни в JSON-поле, ни в десяток физических таблиц, которые вы заводите руками.
Что это даёт на практике
Честный LINQ на уровне СУБД. Данные лежат в типизированных колонках, а метаданные структур позволяют движку собрать нативный SQL: Where / OrderBy / GroupBy / оконные функции идут по реальным индексам базы, а не перебором JSON в памяти бэкенда.
Загрузка за один запрос без каскада JOIN-ов. Чтобы поднять объект со всей глубиной вложенности (пусть там 20–30 списков), не нужен каскад JOIN, как у EF с .Include(). Плоская структура забирается из _values одним запросом и собирается в объект в памяти.
Точечный Change Tracking (Pro). При сохранении Pro-версия строит деревья ValueTreeNode (память против БД), сравнивает их (ValueTreeBuilder / ValueTreeDiff) и шлёт UPDATE только по изменившимся узлам — граф целиком не перезаписывается.
Итог: redb совмещает удобство работы с объектами «как с документами» и фундамент реляционной СУБД — типизацию, индексы, FK и запросы, которые исполняет база, а не бэкенд. Ключ к этому — не блоб и не плоский мешок атрибутов, а persisted-RTTI: types → schemes → structures → values.
Информационные технологии. Проблемы и решения – IT'DAYS
Сегодня всё чаще говорят: импортозамещение заканчивается там, где начинается переписывание миллионов строк бизнес-логики.
Именно поэтому всё больший интерес вызывают полиглотные СУБД, которые позволяют заменить СУБД, а не приложение, сохранив привычные языки программирования и существующую бизнес-логику.
Digital Q.DataBase — именно такая СУБД. Она воспроизводит функциональные возможности Microsoft SQL Server и Oracle Database, позволяя существенно сократить объём доработок существующих информационных систем при миграции.
Отличный повод вспомнить моё выступление на международной конференции «Информационные технологии. Проблемы и решения – IT'DAYS» в Уфе.
► Бесплатная полнофункциональная версия дистрибутива (до 8 ядер) с возможностью использования в том числе в коммерческих целях.
Приглашаем на вебинар «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase»
10 августа в 13:00 (мск) компания «Диасофт» проведет практический вебинар о новых возможностях Digital Q.DataBase «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase».
Вебинар «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase»
Ключевые темы:
Полиглотная архитектура Digital Q.DataBase. Как в единой среде работать с базами PostgreSQL, Microsoft SQL Server и Oracle
Симбиоз СУБД и AI. Поддержка векторных операций и интеграция с большими языковыми моделями (LLM) под капотом СУБД
Высокая скорость работы с данными. Архитектура и новые возможности встроенного KV-хранилища DGrid для сверхбыстрого доступа к информации
Развитие RuDB. Обзор новой функциональности и обновленных пакетов платформы
Как реализовать семантический поиск для RAG-архитектуры в PostgreSQL без усложнения инфраструктуры?
Ситуация: вы разрабатываете чат-бота для техподдержки на базе RAG-архитектуры. Используете PostgreSQL как хранилище знаний и делаете поиск по текстовым полям, но качество ответов нестабильное: система плохо справляется с синонимами, профессиональным сленгом и переформулировками запросов. Обязательно ли внедрять отдельную векторную базу данных, или можно реализовать семантический поиск прямо в PostgreSQL? Возможна ли простая проверка продуктовой гипотезы без усложнения архитектуры?
Да, семантический поиск в RAG-сценариях можно реализовать прямо в PostgreSQL без выделенной векторной базы данных (ClickHouse, Opensearch, Qdrant, Milvus и т. д).
Для этого используется PostgreSQL + расширение pgvector, которое добавляет поддержку хранения эмбеддингов (векторов) и поиск по расстоянию до ближайших соседей (KNN) прямо внутри SQL-движка. Разберем, как это работает на практике.
В RAG-пайплайне текст документов и запрос пользователя преобразуются в векторные представления. PostgreSQL хранит эти векторы в таблице и позволяет выполнять поиск по смысловой близости, а не по точному совпадению слов.
Для этой задачи будем использовать pgvector — это расширение к PostgreSQL, которое добавляет тип данных vector и операторы поиска по расстоянию до ближайших соседей (KNN).
Поддерживаются три основные метрики сравнения векторов:
L2 (евклидово расстояние) — классическое расстояние между двумя точками в многомерном пространстве. Хорошо работает, если векторы не нормализованы и распределение значений относительно равномерное.
Cosine similarity (косинусное сходство). В отличие от предыдущей метрики измеряет не абсолютное расстояние, а угол между двумя векторами. Подходит для текстовых эмбеддингов, где важна направленность, а не масштаб. Требует нормализации векторов.
Inner product (внутреннее произведение) — скалярное произведение двух векторов. Может использоваться как прокси для оценки «сходства» при обучении моделей и в задачах ранжирования.
Допустим, мы получаем на наш запрос именно такой вектор от модели OpenAI. Для хранения создаем таблицу с типом VECTOR:
CREATE TABLE items (
id SERIAL PRIMARY KEY,
title TEXT,
embedding VECTOR(1536)
);
Добавим данные для нескольких векторов разных объектов:
Теперь сравним их попарно и отсортируем по расстоянию:
SELECT
a.title AS title_a,
b.title AS title_b,
a.embedding <-> b.embedding AS distance
FROM items a
JOIN items b ON a.id < b.id
ORDER BY distance;
Оператор <-> здесь вычисляет расстояние между двумя векторами. Таким образом, мы можем оценивать степень семантической близости любых объектов, представленных векторами. Какая именно метрика используется, зависит от операторного класса, заданного при создании индекса.
В подобных RAG-сценариях нет необходимости сразу вводить отдельный класс инфраструктуры типа векторная БД. Семантический поиск можно реализовать эволюционно поверх существующего PostgreSQL.
А если вы не хотите самостоятельно заниматься настройкой индексов, тюнингом памяти и производительности, а также обновлением версии PostgreSQL, то воспользуйтесь DBaaS от Selectel. Мы предоставим вам кластер PostgreSQL с преднастроенными расширениями, готовый к эксплуатации под нагрузкой. Это позволит сосредоточиться на RAG-логике и качестве поиска, а не на инфраструктурной оптимизации.
Как разрешить пользователю реплики удаленно подключаться к Master-серверу PostgreSQL?
Вы настраиваете отказоустойчивый кластер баз данных. При попытке синхронизировать реплику с мастер-сервером соединение обрывается с ошибками сетевого доступа. В каком конфигурационном файле и как именно нужно прописать доступы, чтобы Master принял входящее подключение?
По умолчанию PostgreSQL придерживается строгой политики безопасности и блокирует любые удаленные попытки подключения, если они не разрешены в подсистеме авторизации.
Чтобы решить эту проблему, необходимо отредактировать конфигурационный файл клиентской аутентификации pg_hba.conf на стороне Master-сервера и явно разрешить репликацию для IP-адреса вашей реплики.
Для доступа к реплицируемым данным у пользователя replicator должна быть привилегия replication:
ALTER ROLE replicator WITH REPLICATION;
Предварительно ознакомьтесь с порядком применения правил в pg_hba.conf в официальной документации.
Чтобы PostgreSQL применил изменения в конфигурации авторизации, выполните reload службы в терминале:
systemctl reload postgresql
В качестве альтернативы можно отправить сигнал процессу postmaster с помощью pg_ctl reload, вызовом SQL-функции pg_reload_conf() или используя kill -HUP.
После применения изменений Master-сервер начнет принимать входящие пакеты от указанного IP-адреса, и процесс репликации сможет успешно инициализироваться.
На первый взгляд, настройка репликации в PostgreSQL кажется простой задачей: достаточно открыть доступ в pg_hba.conf и подключить standby-сервер.
Но в production-инфраструктуре за этой «простой настройкой» скрывается целый стек инженерных задач: необходимо следить за консистентностью WAL-журнала, контролировать лаг между репликами, обеспечивать безопасную сетевую доступность между узлами, настраивать резервное копирование, регулярно тестировать сценарии аварийного переключения и быть готовым вручную восстанавливать кластер в случае деградации одного из серверов.
Поэтому в ряде сценариев современные команды переходят от self-managed PostgreSQL к PaaS-решениям вроде Managed Databases, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.
Это позволяет сократить операционные расходы на сопровождение инфраструктуры и снизить риск простоев критичных сервисов.
Приглашаем на пятилетие «Тантор Лабс». 10 сентября - Tantor JAM 2026
Первый юбилей Tantor — пять лет с момента основания компании. За это время мы прошли путь от стартапа до технологического лидера, одного из ведущих российских разработчиков в области управления и хранения данных, создали собственную экосистему продуктов и собрали вокруг себя сообщество, которое сегодня во многом определяет развитие российского рынка СУБД.
Программу скоро представим. Среди главных премьер:
Новое поколение Платформы Tantor, основанное на AI-first подходе. Представим ИИ-администратора БД с целым роем специализированных ИИ-агентов, которые возьмут на себя рутинные операции по работе с СУБД.
Результаты испытаний МБД Tantor XData Gen3 на различных профилях нагрузки. Покажем, как enterprise-технологии, ранее доступные только в зарубежных решениях, — независимое масштабирование Compute и Storage, RDMA, распределенная файловая система и полноценный HTAP — становятся доступны в российском ПАКе.
Подробнее расскажем о Tantor Polar — новой распределенной СУБД, открывающей следующий этап развития российских PostgreSQL-технологий с полным сохранением совместимости с экосистемой Postgres.
Вас ждут выступления руководителей разработки, общение с инженерами, архитекторами, заказчиками и партнерами, а также праздничная программа в честь пятилетия компании.
1 июля мы провели вебинар, посвящённый новым возможностям Digital Q.DataBase 18.2.
В рамках вебинара я, Андрей Жуйков, амбассадор компании «Диасофт», рассказал о ключевых возможностях Digital Q.DataBase 18.2 — масштабном обновлении, направленном на развитие совместимости с корпоративными СУБД и упрощение миграции существующих систем.
Изменения коснулись Microsoft SQL Server-направления: расширена поддержка T-SQL, Service Broker, CLR-сборок, механизма CDC, а также появилась служба отчётов Digital Q.DataBase, совместимая с SQL Server Reporting Services (SSRS).
Отдельное внимание уделено Oracle-направлению: расширена поддержка Oracle-совместимых пакетов, курсоров и Bind-переменных, улучшена работа JDBC-драйвера, доработаны средства миграции Oracle-объектов, а также появилась новая технология автоматизированного перевода Oracle Forms в современные приложения.
На вебинаре рассмотрим ключевые изменения релиза, покажем их практическое применение и расскажем, как новые возможности помогают ускорить миграцию корпоративных систем и снизить затраты на переход на российскую СУБД.
В программе:
🔹 Обзор Digital Q.DataBase 18.2 Ключевые изменения релиза. Развитие совместимости с Microsoft SQL Server и Oracle. Новые возможности для миграции корпоративных систем.
🔹 Новая версия CDC Обновлённый механизм Change Data Capture. Новый веб-интерфейс управления. Сценарии применения и преимущества.
🔹 Новые возможности миграции и совместимости Расширение совместимости с Microsoft SQL Server. Новые Oracle-пакеты и развитие Oracle-диалекта. Поддержка CLR-сборок. Развитие Service Broker.
🔹 Служба отчётов Digital Q.DataBase Аналог SQL Server Reporting Services (SSRS). Поддержка RDL-отчётов. Формирование отчётов в HTML и PDF.
🔹 Новая технология перевода Oracle Forms Автоматизированный перевод Oracle Forms в современные приложения. Архитектура решения. Демонстрация технологии.
► Бесплатная полнофункциональная версия дистрибутива (до 8 ядер) с возможностью использования в том числе в коммерческих целях.
В этом докладе Илья Виссарионов рассказывает о практическом опыте компании «Диасофт» по импортозамещению крупной автоматизированной банковской системы, которая десятилетиями работала на Microsoft SQL Server.
Главной особенностью проекта стало то, что значительная часть бизнес-логики была реализована в виде хранимых процедур. Полное переписывание миллионов строк SQL-кода оказалось бы слишком дорогим и длительным, поэтому был выбран другой путь — развитие Digital Q.DataBase с максимальной совместимостью с Microsoft SQL Server и сохранением существующих приложений.
В докладе подробно рассматриваются реальные технические проблемы, с которыми столкнулась команда при переносе банковской системы на PostgreSQL-совместимую платформу: различия в типах данных, работе процедур, оптимизаторе запросов, производительности, временных таблицах, пользовательских типах данных и других механизмах СУБД.
Отдельное внимание уделено нагрузочному тестированию. Автор показывает, как поэтапная оптимизация Digital Q.DataBase позволила добиться производительности, сравнимой с Microsoft SQL Server, а по ряду операций — превзойти её, при этом сохранив существующую бизнес-логику без масштабного переписывания.
В этом видео вы узнаете:
🔹 почему импортозамещение крупных банковских систем требует особого подхода; 🔹 с какими проблемами столкнулась команда при переносе АБС с Microsoft SQL Server; 🔹 почему стандартного PostgreSQL оказалось недостаточно; 🔹 какие механизмы совместимости были реализованы в Digital Q.DataBase; 🔹 как удалось сохранить существующий T-SQL-код без его переписывания; 🔹 какие доработки были выполнены для повышения производительности; 🔹 как проводилось нагрузочное тестирование на реальных банковских сценариях; 🔹 каких результатов удалось добиться по сравнению с Microsoft SQL Server.
Если вас интересуют вопросы импортозамещения СУБД, миграции корпоративных систем или построения PostgreSQL-совместимых платформ корпоративного уровня — этот доклад будет полезен разработчикам, архитекторам, администраторам баз данных и техническим руководителям.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений. Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
Как мы воспроизводим функциональность Oracle и создаем аналоги DBMS-пакетов.
В предыдущем посте я рассказывал о технологии «Полиглот» в Digital Q.DataBase — возможности исполнять T-SQL "на лету" наряду с родным PL/pgSQL, что позволяет мигрировать приложения с Microsoft SQL Server.
Но полиглотность Digital Q.DataBase этим не ограничивается.
Сегодня хочу поделиться выступлением моего коллеги Ильи Лебедева, посвящённым Oracle-направлению. В докладе он подробно рассказывает о поддержке PL/SQL и о том, как Digital Q.DataBase помогает переносить системы с Oracle, сохраняя серверную бизнес-логику и клиентские приложения без дорогостоящей переработки.
В этом выступлении обсуждаются:
🔹 Как Digital Q.DataBase реализует полноценную поддержку Oracle-диалекта, включая пакеты, DBMS-пакеты и PL/SQL-код. 🔹 Почему SQL- и PL/SQL-код может выполняться без изменений. 🔹 Как работает мастер переноса баз данных и какие скорости миграции можно получить на практике. 🔹 Каким образом обеспечивается бесшовное подключение существующих приложений через OCI и JDBC. 🔹 Почему переход с Oracle на Digital Q.DataBase может занять месяцы вместо лет. 🔹 Как накопленный опыт миграций позволяет ускорять последующие проекты и снижать объем доработок.
В докладе также показаны реальные сценарии переноса корпоративных систем, демонстрация работы клиентских приложений после замены СУБД и подход компании к развитию совместимости с Oracle на основе запросов заказчиков.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений. Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
В этом докладе я (Жуйков Андрей, амбассадор компании «Диасофт») рассказываю о подходе Digital Q.DataBase к импортозамещению зарубежных СУБД и миграции корпоративных систем без переписывания прикладного кода.
В видео рассмотрены:
🔹 архитектура и возможности Digital Q.DataBase; 🔹 технология Polyglot и поддержка нескольких SQL-диалектов в одной СУБД; 🔹 совместимость с Microsoft SQL Server и Oracle; 🔹 исполнение T-SQL и PL/SQL без изменения бизнес-логики приложений; 🔹 поддержка протокола TDS и работа со стандартными драйверами Microsoft; 🔹 миграция 1С с Microsoft SQL Server на Digital Q.DataBase; 🔹 демонстрация работы через DBeaver, SQL Server Management Studio и Python; 🔹 поддержка Service Broker, Reporting Services и CLR-сборок; 🔹 примеры реальных проектов и опыт внедрения у заказчиков.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений.
Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
Определяет представление планировщика об эффективном размере дискового кеша, доступном для одного запроса. Это представление влияет на оценку стоимости использования индекса; чем выше это значение, тем больше вероятность, что будет применяться сканирование по индексу, чем ниже, тем более вероятно, что будет выбрано последовательное сканирование.
Вот прямо с первых строк мозги выносит: при чём тут оценка (ОЦЕНКА!) размера дискового кэша и выбор между индексным или полным сканированием? Не знаю, кому как, но лично мне совсем непонятно. Следующее, если effective_cache_size показывает оценку размера ДИСКОВОГО кеша (для меня одного словосочетание “дисковый кэш” означает “кэш файловой системы”?), то откуда взялась рекомендация в значение 3/4 размера оперативной памяти, если 1/4 - это shared_buffers? Рекомендатели, ау! 1/4 + 3/4 = 1, арифметика, начальная школа. А где СУБД должна выполнять манипуляции с данными? В свопе? Всё остальное описание совершенно не добавляет ясности по использованию данного параметра, увы нам, постгресовым администраторам баз данных.
Кратко. Главное. Данный параметр показывает ОБЩИЙ размер кэша: постгресовый shared_buffersплюс (плюс выделен жирным шрифтом в оригинальной статье!) кэш файловой системы. С этим уточнением рекомендация в 3/4 размера оперативной памяти выглядит приемлемой. Следующее. Обсуждаемый параметр применяется для вычисления вероятности того, что однажды прочитанные данные будут находиться в кэше при повторном обращении в рамках ОДНОГО запроса. Т.е. для предпочтения соединения таблиц вложенным циклом (Nested loop join) при выборе методов соединения. Если высока вероятность того, что данных при повторном запросе в кэше не окажется, то будет выбрано либо полное сканирование таблиц(ы), либо сканирование по битовой маске, либо соединение хешем (hash join), либо соединение слиянием (merge join). Далее. Этот параметр - верхняя оценка, завышенное значение не приводит к серьёзным проблемам (по крайней мере в статье об этом говорится). Ограничение. effective_cache_size должен быть больше shared_buffers, ибо меньшее значение является бессмысленным (по статье).
30 июня эксперты «Тантор Лабс» представят разбор Tantor XData Gen3 — третьего поколения машины баз данных для высоконагруженных корпоративных систем, реализующей ряд технологий, ранее доступных в таких западных продуктах как Oracle Exadata, SAP HANA и IBM Netezza.
В программе:
эволюция архитектуры Tantor XData и ключевые изменения в Gen3: независимое масштабирование подсистем вычислений и хранения, полноценная обработка смешанной нагрузки (HTAP) на едином наборе данных;
новые возможности платформы и сценарии их применения;
устройство и особенности распределенной СУБД Tantor Polar;
организация вычислительных ресурсов и ресурсов хранения;
инструменты управления и мониторинга.
Отдельный блок будет посвящён практической работе с машиной баз данных. Пройдем интерактив с реальным ситуациями, демонстрирующими преимущества новой машины баз данных перед классическими СУБД.
Эксперты мероприятия:
Вадим Яценко, генеральный директор «Тантор Лабс»
Сергей Серегин, руководитель технического пресейл «Тантор Лабс».
Мой опыт с Supabase: 8 неочевидных костылей, о которых молчат в красивых туториалах.
Все вокруг хвалят Supabase за скорость. И да, я тоже повелся. Как бэкендера меня поначалу знатно корежило от того, что фронт ходит тупо прямиком в базу. Но ради быстрой доставки фичей я зажмурился.
Спойлер: пилится-то всё реально быстро. Только потом ты ловишь тихие баги, пропадающие логи и жесткий вендор-лок. Я собрал на Supabase уже несколько проектов и успел поседеть.
Короче, вот за что вы будете страдать на бесплатном тарифе (да и не только на нем).
Логи. Их просто нет Точнее, они живут ровно 24 часа. Упало что-то в пятницу вечеро - в понедельник с утра ты дебажишь святым духом. Встроенный поиск это вообще кровь из глаз. Без какого-нибудь Datadog или Logflare там тупо не выжить.
Edge-функции и проклятые холодные старты Это отдельный котел. Писать надо на Deno, так что половина привычных npm-пакетов идет лесом. Лимиты на вызовы жесткие, долгую таску не запустить. Но самое бесячее — холодные старты. Пока поднимется пул коннектов к базе, проходит до трех секунд. В моем сервисе post-cooler.ruedge-функция отдает HTML для линк-страничек. Я смотрю в метрики и плачу: кликов куча, а дожидаются загрузки единицы. Конверсия просто умирает на этапе бесконечного лоадера.
Палево с доменами в OAuth Юзер логинится через Google, а в окне авторизации торчит <project-id>.supabase.co. Я когда делал photo math, целый час дебажил эту хрень. Думал, что сам где-то накосячил — на локалке-то всё выглядело нормально! Оказалось, не баг, а фича. Хочешь свой домен? Плати.
Хаос со схемами БД Экспорт схем из дашборда выпилили еще в 2025 году. Сейчас помогаю проекту the-signal переехать на селф-хост. До этого код там писали vibe-кодеры, которые вообще не парились про миграции. Вытащить дамп схемы из облака было той еще болью. Без жесткой дисциплины база очень быстро превращается в неуправляемую помойку.
Тормоза локальной разработки Я постоянно прыгаю между проектами. И каждый гребаный раз supabase start лезет тянуть свежие Docker-образы. Поднимает 10+ контейнеров, а ты сидишь и тупишь в терминал. Весь кайф от "быстрой" разработки улетучивается.
Тихие RLS-ошибки RLS (Row Level Security) ошибается молча. Накосячил в политиках? БД тебе не скажет. UPDATE просто вернет 0 affected rows, а SELECT подтянет половину данных.
Транзакции и боль SQL-функций Через REST API нельзя сделать нормальную транзакцию на несколько таблиц. Нужно атомарно создать юзера, профиль и настройки? Обломись. У меня пока ничего не отвалилось, но я с ужасом жду, когда в базе начнут копиться "осиротевшие" записи. Чтобы это обойти, приходится писать логику на PL/pgSQL прямо в базе. Редактор там примитивный, автокомплита толком нет и дебажить то еще удовольствие.
Вендор-лок Клиентский SDK намертво завязан на специфичный синтаксис PostgREST и их собственные токены. Если однажды решишь переехать на нормальный самописный бэк: придется рефакторить вообще весь клиентский код.
Короче. Для MVP или пет-проекта, чтобы просто проверить гипотезу на коленке - это топ. Да, часть этих костылей можно вылечить, если закинуть денег и перейти на платную версию. Но возникает резонный вопрос: за те же 25 баксов в месяц можно спокойно поднять Supabase на нормальной VPS-ке и вообще забыть про лимиты.
Кто еще сидит на Supabase или Firebase? С чем боретесь? И есть тут те, кто уже психанул и переехал на свой бэк?
Сегодня к вечеру я совсем обленился и решил доверить нейронке storege создать к коннектору в библиотеку redb.route используя redb Изучала дольше чем писала. 😊 Накидала в одну сессию за один проход с тестами. __ Аудитория: разработчики уже подключают DSL-маршруты к redb.Route, которые хотят, чтобы LLM был полноценным пользователем конвейера - с памятью, бюджетом, разрешениями и аудиторским журналом, а не HTTP—вызовом без сохранения состояния, который ничего не оставляет после себя. единый линейный маршрут.Услуги.AddRedbLlmStorage() — переключает цикл работы агента с "забывает все при перезапуске" на постоянную систему по умолчанию. Все пять поверхностей (расшифровки, утверждения, бюджеты, идемпотентность, аудит) перемещаются в redb. Ни одна строка кода маршрута не меняется — ваш существующий .To("llm://claude") начинает сохраняться сам по себе.
Тут в ленту прилетела новость, которая касается всех постгресменов, кто пользуется pgbackrest-ом для создания резервных копий. Либо собирается им пользоваться. А именно, создатель и разработчик проекта закончил работу над ним: https://github.com/pgbackrest/pgbackrest#notice-of-obsolescence. Грусть, печаль, тоска, тлен и безысходность. :( И статью править, и исходный материал в ЖЖ.
Вебинар о том, как обеспечить стабильность баз данных при росте проекта и нагрузок
Самостоятельное администрирование баз данных может превратиться в рутину: постоянные обновления, бэкапы, мониторинг и работа с нагрузкой. С ростом проекта стандартных настроек уже не хватает, а риск просадок и простоев из-за ошибок в конфигурации становится выше.
Это третий вебинар из большого трека про эволюцию приложения в облаке. На этот раз разберем, как передать обслуживание PostgreSQL управляемому сервису в облаке и настроить архитектуру Master/Replica для стабильной работы при высоких нагрузках.
О чем будем говорить:
сравним управляемую и self-hosted СУБД PostgreSQL: выясним, когда пора задуматься о переезде;
разберем ключевые метрики БД: на что обращать внимание в мониторинге, чтобы не доводить до инцидента;
обсудим, как архитектура Master/Replica повышает отказоустойчивость приложения.
После теории будет насыщенное демо, на котором покажем, как добавить в сервис поддержку нескольких реплик и разгрузить базу на чтении. Затем проведем нагрузочное тестирование и сравним показатели до и после оптимизации. Еще покажем, как организовать резервное копирование, разделить трафик на чтение и запись и повысить отказоустойчивость приложения.
Вебинар будет полезен бэкенд-разработчикам, DevOps- и SRE-инженерам, архитекторам и тимлидам, которые отвечают за стабильность базы данных, производительность сервисов и развитие приложения под растущей нагрузкой.
Мировой лидер по добыче алмазов АЛРОСА перевел DIrectum RX на СУБД Tantor Postgres, проект занял всего 5 месяцев. При этом бизнес-процессы работали в штатном режиме, сроки не сместились, бюджет не увеличился.
В результате компания получила обновленный ИТ-контур, он обеспечивает безопасность критически важных данных и стабильную производительность корпоративных систем.
23 апреля в 11:00 мск на бесплатном вебинаре эксперты АЛРОСА, «Тантор Лабс», «СТАРКОВ Групп» и Directum поделятся подробностями кейса.
Для участия нужна только регистрация. Встретимся на вебинаре!
Встраивание вычислений в PostgreSQL: PL*, extensions, а теперь и WASM
В рамках выступления на PG BootCamp Russia 2026 Дмитрий Дорофеев, главный конструктор Luxms, рассказал о том, как сегодня развивается встраивание вычислений в PostgreSQL: от классических процедурных языков (PL/pgSQL, PL/Python и других) до новых возможностей с использованием WebAssembly (WASM).
В PostgreSQL исторически поддерживается несколько десятков языков программирования. Если этого недостаточно, можно воспользоваться готовым расширением из огромной экосистемы либо написать своё. Прогресс не стоит на месте, и теперь для выполнения стороннего кода в PostgreSQL можно использовать WASM.
На примере Luxms BI я расскажу, как мы автоматически генерируем Swagger-документацию прямо внутри PostgreSQL с помощью open-source технологий и WASM.
🚨 Мы в Diasoft запускаем свою серию мероприятий по СУБД. Первое — уже 21 апреля 2026: конференция о промышленной эксплуатации и архитектуре корпоративных данных.
❯ Место проведения — Москва, Кибердом.
Я выступлю с двумя докладами:
🔥 Как мы воспроизводим функциональность MS SQL и переносим решения без переписывания 🔥 Digital Q.CDC — когда критична синхронизация изменений данных.
❯ В нашей программе намечается много интересного, в том числе обсудим:
🔹 как мы воспроизводим функциональность Oracle 🔹 практика импортозамещения и работа с высоконагруженными системами на базе Digital Q.DataBase 🔹 Low-Code подходы и замещение зарубежных платформ 🔹 единая работа данных для OLTP и OLAP 🔹 развитие инструментов управления СУБД 🔹 как формируется СУБД за счет объединения компетенций и технологий
Наши профессионалы подробно объяснят реальные кейсы и практику внедрения.
🔹 Всем привет. Сегодня хочу рассказать Вам о том, как мы склонировали у себя один из самых "прикладных" сервисов из поставки Microsoft SQL Server.
➡️ Речь пойдет об SQL Server Reporting Services (SSRS) - механизме, который позволяет получать разнообразные отчеты, запрашивая их построение по API или по расписанию.
➡️ Представьте ситуацию: Вы использовали Microsoft SQL Server и у Вас было несколько сотен разнообразных отчетов, что ранее строились на основе данных в Ваших БД. И тут импортозамещение! Надо переходить на российское решение из Реестра Минцифры. Для замены СУБД самый легкий вариант такого перехода - Digital Q.DataBase. Мастер переноса БД поможет перенести данные, Мастер сравнения БД проверит корректность переноса, Digital Q.CDC обеспечит синхронизацию данных в обеих СУБД, что позволит сократить до нескольких минут сам момент перехода. Но что делать с сотнями отчётов, что привыкли получать Ваши пользователи?
Оставить как есть, пусть строятся при помощи зарубежного инструмента? Вряд-ли это приемлемо. Какое-то очень кусочное импортозамещение получается!
Переписать на другом инструменте? Даже из расчета по дню на отчёт это сотни человеко-дней "ручного труда", а потом тестирование, выгребание ошибок, восстановление порушенных интеграций (построение некоторых отчетов могло запрашиваться извне, через API). Тоже так себе вариант!
➡️ Мы предлагаем более живую альтернативу: воспользоваться нашей реинкарнацией службы отчетов.
На приложенных скриншотах два отчёта. Один построен в оригинальном инструменте, второй у нас. Как видите, они очень похожи, более того построены по одному и тому же шаблону, что был перенесен из оригинала к нам при замене СУБД.
Внешний вид и API - все сохранено. Как говорят наши "заокеанские партнеры" - настоящий "drop-in replacement" (безшовная замена одного инструмента другим). Именно так и должно выглядеть хорошо проработанное импортозамещение.
Худший бэкап — не тот, что не восстановился. А тот, что положил прод.
Что, если post-script не отработал? Моргнула сеть или случился таймаут. Внешний оркестратор просто пишет в лог failed и снимает задачу. А вот PostgreSQL об этом не знает. База остается в режиме бэкапа и начинает непрерывно копить WAL-файлы, ожидая команды на завершение.
Получается, что инструмент для защиты бизнеса от даунтайма, своими руками этот даунтайм и устроил.
Уметь дернуть pg_backup_start( ) — мало. Если СРК не имеет встроенного watchdog-механизма для сброса зависших сессий, резервное копирование превращается в угрозу доступности. Разделение ответственности — правильный архитектурный подход, но он означает, что защита базы от переполнения диска полностью ложится на ваши плечи.
О зависшем backup mode, разрывах PITR и других неудобных вопросах эксплуатации PostgreSQL совместно с Акурой поговорим врежиме live-демо на вебинаре 26 марта в 11:00 (МСК).
Регистрация по ссылке. Приносите в комментарии свои вопросы.
Друзья, Digital Q.DataBase позволяет Вам не только сохранить прикладную логику СУБД Microsoft и Oracle.
🔹 В связке с другим нашим продуктом, предназначенным для замены SAP NetWeaver, Вы получаете возможность уйти от использования продуктов SAP без переписывания систем и без переписывания бизнес-логики.
Что это означает на практике:
🔹 ABAP-приложения продолжают работать на новой платформе 🔹 Данные и обработка переносятся в Digital Q.DataBase 🔹 Вся бизнес-логика сохраняется без изменений 🔹 Формируется импортонезависимый стек из отечественного ПО
🔹 В этом видео:
ABAP-код → сохранение → активация → преобразование в C++ → компиляция → установка на сервер → запуск
📎 Полезные ссылки 🔹 Отдельный лендинг по замене SAP: renovation.diasoft.ru 🔹 Бесплатное получение СУБД дистрибутива: database.diasoft.ru 🔹 Документация: доступна внутри дистрибутива 🔹 Telegram-сообщество Digital Q.DataBase: t.me/dqdatabase
🔹 Стоит ещё раз подчеркнуть важную мысль: переход на российскую СУБД не обязательно означает полное переписывание системы.
До сих пор многие не воспринимают это как реальную возможность. Крупные системы на Oracle или Microsoft можно переводить иначе. Без многолетней переработки всего кода. Достаточно перенести данные и изменить настройки.
При этом важно понимать условие: такой подход работает, если выбранная СУБД изначально к этому подготовлена. В ней должны быть реализованы необходимые доработки для совместимости, включая клонирование функциональности систем Microsoft и Oracle.
Традиционный путь — это огромные команды разработчиков, длительная проверка корректности переписанного кода, принятие сложных архитектурных решений. Более того, в процессе такого переписывания зачастую приходится менять саму архитектуру системы и фактически перестраивать её заново.
🔹 Мы предлагаем другой подход. В нашем подходе меняется само представление о миграции: не обязательно адаптировать приложение под PostgreSQL. Можно пойти другим путём, реализовать в СУБД функциональность, совместимую с зарубежными системами.
🔹 Если бы такой подход начали применять раньше, страна могла бы сэкономить колоссальные ресурсы.
Речь идёт о миллиардах рублей, которые уже ушли и продолжают сегодня уходить на переписывание систем.
📎 Полезные ссылки 🔹 Бесплатное получение дистрибутива: database.diasoft.ru 🔹 Документация: доступна внутри дистрибутива 🔹 Telegram-сообщество Digital Q.DataBase: t.me/dqdatabase
Неудобные вопросы про бэкап PostgreSQL: открытый разбор на вебинаре
Вокруг бэкапа PostgreSQL легко создать иллюзию, что все уже решено. Достаточно добавить в текст WAL, PITR, пару слов про консистентность и назвать агент «умным». Проблема в том, что в проде такие формулировки мало что гарантируют.
Можно ли вообще считать решение PostgreSQL-aware, если оно не живет внутри логики самой СУБД? Где проходит граница между нативными механизмами PostgreSQL и внешней платформой? Что происходит, если не доехал WAL-сегмент, не завершился post-script или восстанавливать нужно не весь инстанс, а один объект?
Из таких вопросов и вырос отдельный вебинар про PostgreSQL в Акуре, в формате открытого инженерного разбора: что здесь должна делать сама СУБД, что имеет смысл выносить во внешний слой, где начинаются реальные эксплуатационные проблемы и какие ограничения в таком подходе нельзя замалчивать.
План такой:
отдельно пройтись по WAL, PITR и консистентности;
обсудить, где файловый агент уместен, а где уже нет;
разобрать сценарии с ошибками pre/post-скриптов;
поговорить про восстановление в безопасную локацию и ручной recovery;
отдельно затронуть вопрос масштаба: почему на двух базах хватает shell-скриптов, а на пятидесяти уже начинается совсем другая жизнь.
26 марта 2026, 11:00 (МСК) Регистрация по ссылке. Приносите в комментарии вопросы, которые особенно хочется поднять в эфире.
PostgreSQL в Docker: запуск, настройка, типичные ошибки
Устанавливать PostgreSQL напрямую в систему — значит разбираться с зависимостями, версиями и мусором, который остается после удаления. В контейнере база поднимается за секунды, одинаково работает на любой машине в команде и легко пересоздается под новый проект.
В новой статье на сайте Рег.облака разобрали полный путь: от установки Docker на Ubuntu 24.04 до работы с томами, своим postgresql.conf и настройки локали. Отдельно собрали типичные ошибки и объяснили, как их чинить.
🚀 Snuffer: Как я превратил Android-смартфоны в распределенную сеть мониторинга (и спас свои нервы)
Меня зовут Виталий, я из команды ArcaneGaming. Сегодня я хочу рассказать вам о своем пет-проекте, который немного вышел из-под контроля и превратился в полноценный продукт. Встречайте - Snuffer !
😫 С чего всё началось? Знаете это чувство, когда вам пишет клиент (или, что еще хуже, мама):
"А почему сайт не открывается?" И ты такой: "Да ладно, у меня всё работает!" А потом оказывается, что сервер упал 3 часа назад, база данных ушла в дедлок, а ты в это время спокойно пил кофе и смотрел мемы.
Я перепробовал кучу сервисов: UptimeRobot, Pingdom, Better Uptime. Они крутые, спору нет. Но:
Дорого , если нужно много проверок.
Ограниченные локации . Иногда нужно проверить доступность именно из конкретной сети или региона.
Скучно . Где веселье в том, чтобы просто заплатить денег?
И тут я посмотрел на ящик своего стола. Там лежали они... Герои прошлых лет. Samsung Galaxy S7, какой-то старый Xiaomi с треснутым экраном и Pixel первого поколения. Они смотрели на меня своими пыльными камерами и шептали: "Мы еще можем быть полезны..."
И меня осенило! 💡
А что, если использовать эти устройства как узлы мониторинга? Ведь смартфон - это мощный компьютер с Wi-Fi и GSM модулем. Он может пинговать, делать HTTP-запросы, проверять порты. И если раздать такие телефоны друзьям в разных городах (или просто подключить к разным провайдерам), получится настоящая распределенная сеть мониторинга . Так родился Snuffer
📱 Что такое Snuffer? Если говорить умными словами, это распределенная система мониторинга доступности сервисов с использованием мобильных агентов .
Database : PostgreSQL + Prisma (потому что писать SQL руками в 2025 — это моветон, хотя я умею!).
Frontend : React + Tailwind CSS (чтобы было красиво и адаптивно).
Mobile : React Native / Expo (одна кодовая база, минимум боли).
Самое интересное - это архитектура . Сервер раздает "задачи" (tasks) подключенным устройствам через WebSocket. Устройства выполняют проверки и шлют отчеты обратно.
Если устройство говорит "Сайт лежит", сервер не верит ему на слово (вдруг у телефона просто Wi-Fi отвалился?). Он ждет подтверждения от других узлов или от самого сервера. Это минимизирует ложные срабатывания.
🌍 Почему это круто?
Вторая жизнь вещам . Ваши старые гаджеты не загрязняют природу, а приносят пользу. Экологично! 🌱
Полный контроль . Вы сами выбираете, откуда мониторить. Хотите проверить доступность из офиса конкурента? Просто подбросьте им телефон с Snuffer (шутка... или нет?).
Бесплатно (почти). Вы платите только за электричество для зарядки телефона.
Проект живет и развивается. Сейчас я выкатил версию v4.15.11 (да, мы часто обновляемся!). В планах:
iOS версия (Apple, пустите в AppStore, ну пожалуйста!).
Больше типов проверок (например, скриншоты сайтов).
Публичное API.
Если вам интересно попробовать или просто потыкать палочкой — залетайте: 👉 snuffer.net
Буду рад любому фидбеку, критике или просто комментариям.
Коллеги, 03.02.2026, три дня назад я провёл вебинар, посвящённый полиглотности СУБД - умению работать с диалектами PostgreSQL, Oracle и Microsoft в контексте импортозамещения.
Меня зовут Жуйков Андрей, и если будет время - буду рад, если посмотрите запись 👀
«Импортозамещение СУБД по-новому: интеллектуальный подход к замене MS SQL и Oracle»
🔹 Установка и первый запуск Digital Q.DataBase • развёртывание Digital Q.DataBase в Docker-контейнере • установка и настройка Digital Q.DataBase на Ubuntu 24.04 • архитектура, ключевые преимущества и типовые сценарии использования в российских компаниях
🔹 Новые возможности Digital Q.DataBase для импортозамещения • инструменты, упрощающие миграцию с MS SQL и Oracle • как сократить риски и сроки перехода без переписывания приложений
🔹 Практика внедрения и реальные кейсы • Владимир Авсеев показал, как система «Босс-Кадровик», изначально заточенная под MS SQL, успешно работает на Digital Q.DataBase • Анастасия Коршунова (отдел разработки) продемонстрировала примеры успешной интеграции Digital Q.DataBase с 1С и Delphi-приложениями
🔹 Ответы на вопросы • практические нюансы миграции и эксплуатации • ответы на вопросы из реальных проектов от разработчиков Digital Q.DataBase и команды «Босс-Кадровик»
Хочу поделиться записью моего последнего вебинара - в преддверии следующего. Буду рад всем, кто посмотрит.
📘 Часть 1. Теория и философия Digital Q.DataBase Разбираем фундаментальные вопросы: • Как Digital Q.DataBase объединяет три SQL-диалекта (T-SQL, PL/SQL, PL/pgSQL) в одном ядре? • Как продукт обеспечивает простоту и высокую скорость миграции? • Что входит в базовый состав коробочной версии?
🛠 Часть 2. Практика: установка и работа с диалектами • скачиваем и устанавливаем Digital Q.DataBase, • получаем документацию, • выполняем практику по SQL-диалектам на демостендах.
Да, это тот самый момент, когда теория превращается в конкретику - и вы сами видите, как работает гибридная архитектура продукта.
Почему у PWA до сих пор нет полноценного «магазина приложений» — возможно ли это вообще?
Всем привет.
В течение последних месяцев, работая с PWA-приложениями, мы постоянно сталкивались с одним и тем же вопросом:
Почему в 2025 году у PWA до сих пор нет настоящего App Store?
Не просто каталога ссылок, а полноценного магазина приложений — знакомого, вызывающего доверие и понятного обычным пользователям.
При изучении существующих PWA-магазинов и каталогов обнаруживаются одни и те же повторяющиеся проблемы.
⸻
Установка остаётся непонятной для пользователей
Даже сегодня установка PWA вызывает затруднения у обычных пользователей.
Большинство из них не понимают: • когда приложение действительно можно установить, • почему инструкции по установке не совпадают с реальными шагами в их браузере или на устройстве.
Во многих PWA-каталогах всё ограничивается текстовой инструкцией — и на этом взаимодействие с сервисом фактически заканчивается.
⸻
Отсутствие доверия
Со стороны пользователя это проявляется в следующем: • нет содержательных отзывов, • отсутствует история установок, • нет ощущения личной библиотеки приложений.
Со стороны разработчиков наблюдаются крайности: • либо любой может опубликовать приложение без подтверждения права собственности, • либо проверка обязательна, но сложна и ограничена одним способом (например, через DNS-записи).
В итоге доверие не формируется ни у одной из сторон.
⸻
Разработчики — второстепенные участники экосистемы
Распространённые проблемы: • медленные и неудобные процессы публикации, • почти полное отсутствие автоматического заполнения данных из манифеста, • нехватка инструментов, которые были бы полезны разработчику ещё до установки приложения пользователем.
Экосистема не стимулирует разработчиков поддерживать и развивать свои PWA.
⸻
Интерфейс не воспринимается как «нативный»
Это тонкий, но важный момент.
Если магазин: • выглядит как обычный веб-сайт, • не вызывает ассоциаций с App Store или Google Play,
пользователи инстинктивно доверяют ему меньше — даже если сами приложения качественные.
⸻
При этом сами PWA как технология за последние годы заметно повзрослели: офлайн-режим, push-уведомления, installability, Web APIs. Однако именно слой распространения и доверия остаётся самым слабым звеном.
⸻
Главный вопрос, к которому мы пришли
Возможно ли вообще создать PWA-магазин, который: • пользователи будут воспринимать как настоящий магазин приложений, • не станет источником боли для разработчиков, • сможет устойчиво развиваться, а не быть заброшенным через несколько месяцев?
Или же сама идея магазина PWA в текущей экосистеме изначально ошибочна?
Будет интересно узнать ваш опыт.
Вы публиковали PWA-приложения в существующих магазинах или каталогах? Что вызывало наибольшие сложности — у разработчиков или у пользователей?
Открываем доступ по запросу к Yandex Managed Service for Sharded PostgreSQL — сервису на базе технологии SPQR для горизонтального масштабирования PostgreSQL
PostgreSQL по умолчанию не имеет нативной поддержки горизонтального масштабирования — и это вызывает сложности при достижении пределов единственного экземпляра Postgres. В качестве решения часто используют разделение таблиц по ключам и установку рядом с приложением координатора, который знает, на какой шард направить запрос.
Однако у такого подхода множество недостатков: сложность миграций, проблемы с масштабированием метаданных и балансировкой и не только.
Сегодня мы открываем доступ по запросу к управляемому сервису Yandex Managed Service for Sharded PostgreSQL. Новый инструмент создан на базе SPQR (Stateless Postgres Query Router) — это опенсорс‑решение для горизонтального масштабирования PostgreSQL, которое разработано инженерами из команды платформы данных Yandex Cloud и оптимизировано под OLTP‑нагрузки и плавные миграции.
Управляемый сервис на основе SPQR позволит клиентам облачной платформы Yandex Cloud ускорить обработку миллионов транзакций: так, с Sharded PostgreSQL банки и компании из сферы электронной коммерции могут запускать новые ИТ‑продукты в 3–4 раза быстрее. Надёжность технологии шардированного PostgreSQL проверена на проектах Яндекса.
Команда активно развивает технологии PostgreSQL: каждый год в релиз базы данных попадает множество доработок от контрибьюторов из Yandex Cloud:
Инкрементальное улучшение любой популярной технологии зачастую имеет негативные последствия. Построить что‑то новое, ничего не сломав, бывает трудно и в чистом поле, а ядро PostgreSQL в этом смысле — лабиринт с граблями.
Но большинство незавершённых проектов создают инфраструктуру для того, чтобы какие‑то другие проекты могли завершиться и причинить пользу.
Андрей Бородин, руководитель команды разработки СУБД с открытым исходным кодом Yandex Cloud, Major Contributor PostgreSQL
Запустить в Dimension-UI мониторинг данных PostgreSQL с помощью запроса с интервалом 3 сек.
WITH params AS (
SELECT
15 AS total_frames,
20 AS canvas_height,
3 AS frame_duration_sec
),
animation_state AS (
SELECT
(CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP) AS INTEGER) / frame_duration_sec) % total_frames AS frame_idx
FROM params
),
tree_definition AS (
SELECT
frame_id,
y_pos,
CASE
-- ═══════════════════════════════════════
-- ЗВЕЗДА на верхушке
-- ═══════════════════════════════════════
WHEN y_pos = 20 AND frame_id = 7 THEN '*'
-- ═══════════════════════════════════════
-- ВЕРХУШКА елки (острая)
-- ═══════════════════════════════════════
WHEN y_pos = 19 AND frame_id = 7 THEN 'G'
-- ═══════════════════════════════════════
-- ЯРУС 1 (y=16-18) — расширяется книзу
-- ═══════════════════════════════════════
WHEN y_pos = 18 AND frame_id BETWEEN 6 AND 8 THEN 'G'
WHEN y_pos = 17 AND frame_id BETWEEN 5 AND 9 THEN 'G'
WHEN y_pos = 16 AND frame_id BETWEEN 4 AND 10 THEN 'G' -- широкий низ яруса
-- Сужение перед ярусом 2
WHEN y_pos = 15 AND frame_id BETWEEN 5 AND 9 THEN 'G'
-- ═══════════════════════════════════════
-- ЯРУС 2 (y=12-14)
-- ═══════════════════════════════════════
WHEN y_pos = 14 AND frame_id BETWEEN 4 AND 10 THEN 'G'
WHEN y_pos = 13 AND frame_id BETWEEN 3 AND 11 THEN 'G'
WHEN y_pos = 12 AND frame_id BETWEEN 2 AND 12 THEN 'G' -- широкий низ яруса
-- Сужение перед ярусом 3
WHEN y_pos = 11 AND frame_id BETWEEN 4 AND 10 THEN 'G'
-- ═══════════════════════════════════════
-- ЯРУС 3 (y=8-10)
-- ═══════════════════════════════════════
WHEN y_pos = 10 AND frame_id BETWEEN 3 AND 11 THEN 'G'
WHEN y_pos = 9 AND frame_id BETWEEN 2 AND 12 THEN 'G'
WHEN y_pos = 8 AND frame_id BETWEEN 1 AND 13 THEN 'G' -- широкий низ яруса
-- Сужение перед ярусом 4
WHEN y_pos = 7 AND frame_id BETWEEN 3 AND 11 THEN 'G'
-- ═══════════════════════════════════════
-- ЯРУС 4 — нижний, самый широкий (y=4-6)
-- ═══════════════════════════════════════
WHEN y_pos = 6 AND frame_id BETWEEN 2 AND 12 THEN 'G'
WHEN y_pos = 5 AND frame_id BETWEEN 1 AND 13 THEN 'G'
WHEN y_pos = 4 AND frame_id BETWEEN 0 AND 14 THEN 'G' -- во всю ширину!
-- ═══════════════════════════════════════
-- СТВОЛ (y=1-3)
-- ═══════════════════════════════════════
WHEN y_pos BETWEEN 1 AND 3 AND frame_id BETWEEN 6 AND 8 THEN 'T'
-- Всё остальное — фон
ELSE 'S'
END AS pixel_char
FROM generate_series(0, 14) AS frame(frame_id)
CROSS JOIN generate_series(1, 20) AS y(y_pos)
),
pixel_data AS (
SELECT td.*
FROM tree_definition td
JOIN animation_state ast ON td.frame_id = ast.frame_idx
),
layers_logic AS (
SELECT
y_pos,
pixel_char,
MAX(CASE WHEN pixel_char IN ('T', 'G', '*') THEN y_pos ELSE 0 END) OVER () as max_obj_height
FROM pixel_data
)
SELECT
CURRENT_TIMESTAMP as dt,
CASE
WHEN pixel_char = 'T' THEN '4_Trunk'
WHEN pixel_char = 'G' THEN '3_Tree'
WHEN pixel_char = '*' THEN '2_Star'
WHEN pixel_char = 'S' THEN
CASE WHEN y_pos > max_obj_height
p.s. Данные по запросу любезно предоставлены Claude Opus 4.5.
Привет, друзья! Мой коллега Марк, ведущий архитектор GlowByte, поделился в новой статье результатами тестирования YMatrix.
Сразу оговорюсь, что это дополнение к предыдущей статье, для того, чтобы сформировать понимание сравнимости результатов различных форков GreenPlum, поэтому акцентировать внимание будем только на YMatrix. Детали по методике тестирования и как были получены результаты для GP6, GP7 и Cloudberry 1.6, можно прочитать в предыдущей статье по ссылке выше.
Добро пожаловать в статью! Комментарии приветствуются.
Новый курс «Платформа Tantor 6.x» на «Астра Знания»!
Мы подготовили новый курс «Платформа Tantor 6.х», посвященный новым функциям платформы управления любыми Postgres-like СУБД и возможностям, доступным DBA после выхода обновления. Размещен курс на платформе «Астра Знания». Он сочетает структурированный теоретический материал и практические задания, которые помогают закрепить приобретенные знания и навыки.
В программе: ▪️архитектура Платформы и ее возможности ▪️интеграция и работа со Swagger UI ▪️инструменты мониторинга, конфигурирования и обслуживания PostgreSQL ▪️браузер БД ▪️анонимайзер ▪️работа с уведомлениями
Приглашаем на вебинар «Платформа Tantor 6.1. Умный центр администрирования СУБД на основе PostgreSQL».
Управляете парком PostgreSQL-совместимых СУБД и хотите сократить рутину и повысить надёжность? 11 декабря в 11:00 наши эксперты представят актуальный релиз Платформы Tantor 6.1. Платформа Tantor — интеллектуальный центр управления базами данных, который берет на себя массу актуальных задач DBA. На вебинаре покажем, как платформа решает ключевые из них:
Автоматизация вместо рутины: умные алерты, подсказки и встроенный ИИ-ассистент для помощи в повседневной работе;
Безопасность под контролем: централизованный аудит и визуальное управление настройками доступа (pg_hba, pg_ident);
Оптимизация «одной кнопкой»: анализ конфигураций, подбор оптимальных настроек под нагрузку и их групповое применение;
Всё на виду: наглядная топология кластеров, пространств и тенантов;
Лёгкое масштабирование: создание кластеров Tantor XData за пару кликов.
В финале — эксклюзивный анонс: дорожная карта развития Платформы Tantor на 2026 год.
Кому будет полезно: DBA, архитекторам, DevOps-инженерам и руководителям ИТ-направлений, которые работают с БД на основе PostgreSQL.
Честно сравним два подхода и разберем, с какими сложностями и скрытыми рисками можно столкнуться при переходе с on-premise на Managed PostgreSQL в облаке. И, главное, как их избежать.
Поговорим о разделении ответственности за кибербезопасность между облачным провайдером и клиентом. Расскажем, какие задачи лежат на каждой из сторон и как модель разделенной ответственности помогает избежать инцидентов.
Сложное развертывание, тонкая настройка и постоянная зависимость от IT-специалистов растягивают внедрение бизнес-аналитики. На вебинаре покажем, как развернуть полнофункциональную BI-систему в облаке за день.
«Тантор Лабс» активно поддерживает российское сообщество открытой СУБД PostgreSQL. Наши специалисты уже много раз выступали спикерами на официальных комьюнити-мероприятиях PG BootCamp Russia, проводили лекции и мастер-классы.
Делимся с вами подборкой наших выступлений, темы которых можно условно разделить на несколько ключевых направлений.
Внутренности PostgreSQL и оптимизация ядра — для тех, кто хочет понимать СУБД «под капотом»
Кстати, на весенний PG BootCamp Russia 2026, который пройдет в Москве, открыт прием заявок на выступления! Это отличный шанс поделиться знаниями с одним из самых сильных профессиональных сообществ.
Продолжается набор на авторизованный курс по СУБД Tantor Postgres!
Авторизованный курс по администрированию СУБД Tantor Postgres будет полезен администраторам БД, DevOps-инженерам, системным аналитикам и разработчикам. Вы получите практические навыки работы с популярной СУБД напрямую от экспертов «Тантор Лабс», безлимитный доступ к тестовому стенду и всем материалам курса, включая записи.
По окончании курса слушатели курса получат удостоверение о повышении квалификации государственного образца.
Содержание курса построено на балансе 50% теории / 50% практики. Проходит курс под наблюдением преподавателя – эксперта«Тантор Лабс».
Курсы пройдут в онлайн-формате:
с 8 по 12 декабря —в «Сетевой академии Ланит»;
с 22 по 26 декабря — в учебном центре «Микротест».
