SQL *

Привет, Хабр!

Меня зовут Жуйков Андрей, в Диасофт я занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

Импортозамещение СУБД перешло из разряда регуляторных требований в практическую плоскость: компаниям нужно менять платформы без остановки бизнеса. Типичная проблема — огромная экосистема вокруг MS SQL, PostgreSQL или Oracle с тысячами процедур, отчетов и интеграций. Ручной перенос такого объема (например, 900 тысяч строк кода) занимает месяцы и несет риски, при этом даже автоматизация не исключает доработок.

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

В новой версии Digital Q.DataBase существенно переработана архитектура продукта. Вместо единого монолитного решения СУБД получила независимые модули, воспроизводящие функциональность PostgreSQL, Microsoft SQL Server и Oracle Database. Это упрощает установку, сопровождение и обновление системы, а также позволяет использовать только те компоненты, которые действительно необходимы в конкретном проекте.

В этой статье покажу, как установить Digital Q.DataBase 18.2 на Astra Linux 1.8, познакомлю с новой архитектурой продукта и продемонстрирую подключение к каждому из поддерживаемых диалектов.

Продолжаем проводить конкурc SQL в рамках «IT-Планеты 2026». Как обычно во втором этапе участникам было предложено решить пять задач на чистом SQL. Перейдем к рассмотрению задач.

Привет, Хабр! Я — Дмитрий Селищев,  в компании «Синимекс» совмещаю роли руководителя подразделения и разработчика баз данных. В этом материале хочу поделиться историей о том, как простые, но не всегда очевидные приемы помогают кардинально ускорить SQL-запросы. Мы поговорим о стандартных конструкциях CASE и FILTER, которые позволяют писать более чистый код и, что важнее, на порядки сокращать время построения сложных отчетов. Давайте на живых примерах посмотрим, как это работает.

4 июня 2026 вышла PostgreSQL 19 Beta 1. Все пишут про графовые запросы SQL/PGQ, но главная операционная новость в другом: в ядро завезли команду REPACK с неблокирующей опцией CONCURRENTLY — перепаковку раздутых таблиц без ACCESS EXCLUSIVE lock и без внешнего pg_repack. Разбираю по официальному анонсу и release notes: как это работает (спойлер — через слоты репликации, отсюда max_repack_replication_slots), чем отличается от VACUUM FULL и pg_repack, и что именно стоит прогнать на staging до GA — дисковый оверхед, documented-ограничения (команда не MVCC-safe!), бюджет слотов. Плюс честный разбор SQL/PGQ: GRAPH_TABLE убирает отдельный Neo4j для связей фиксированной глубины, но обходы переменной длины в бете пока не поддерживаются. Без ‘я проверил в проде’ — beta в прод не ставят.

Новая статья из цикла про нашу OLTP-СУБД на Rust.

С самого начала мы выбрали MVCC на UNDO-логе вместо версионирования в heap, как в PostgreSQL. И годами повторяли свой же лозунг: «нет VACUUM, нет bloat». Оказалось, это правда ровно наполовину.

Heap и правда не пухнет от истории версий. Но bloat никуда не делся: он переехал в индексы, в мёртвые слоты и в сам UNDO-лог. А сборка мусора из одного механизма незаметно превратилась в пять, и мы только сводим их к единому координатору.

В статье разобрали без прикрас обе стороны. Что UNDO-модель дала: стабильный TID (UPDATE, который не трогает индексы), rollback пропорционально размеру транзакции, аналитику, не дорожающую от write-нагрузки, и AS OF как «машину времени» почти даром. И чем за это платим: главная эксплуатационная цена это долгоживущий снапшот, который молча останавливает очистку для всех.

Вопрос к тем, кто эксплуатировал MVCC-базы под нагрузкой: что меньшее зло — блокировать GC ради долгих транзакций или отдавать «snapshot too old»? Любопытно ваше мнение в комментариях.

Всем привет. На связи Дмитрий Немчин из Т-Банка. Снова буду говорить про Greenplum, но в необычном контексте.

С 2015 года занимаюсь Greenplum: развитием, эксплуатацией, автоматизацией и всем, что обычно появляется вокруг большой аналитической платформы. Когда я пришел, у нас было два production-кластера Greenplum и десятки терабайтов данных. Сейчас production-кластеров около 20 и объемы данных измеряются петабайтами. За это время Greenplum прошел путь от небольшого DWH до центра крупной Дата Платформы. И сейчас это система, которая все еще держит большую часть нагрузки, но постепенно перестает быть точкой будущих инвестиций. 

Переход к такому состоянию системы часто воспринимается болезненно. Особенно если технология долго была центральной для команды и бизнеса. Но сам факт перехода в legacy не означает, что система была плохой или что работа команды обесценилась. Чаще наоборот: legacy становятся решения, которые долго работали, выдержали рост и успели стать частью критичной инфраструктуры. 

В статье хочу разобрать переход на примере Greenplum: что я называю legacy, почему технология начала ограничивать следующий этап роста, какие варианты были у команды и что происходит с людьми, когда привычная система постепенно уходит из фокуса развития. 

Всем привет! Меня зовут Иван Привалов, я разработчик в команде BI Авито Финтеха и в этой статье расскажу, как мы сделали FIFO-сопоставление между N начислений и M списаний для бонусов. Заодно покажу подвох, без которого SQL быстро превращался в тыкву.

Статья будет полезна аналитикам и data-инженерам уровней мидл+, которые работают с финансовыми данными в Trino, Presto и Spark SQL.

JOIN - крайне популярная операция в SQL, о которой еще и спрашивают на 99% собеседований на программиста. Но когда начинаешь впервые разбираться с ней, то постоянно путаешься, какие таблицы соединять и когда именно.

В этой статье простыми словами и с великолепной графикой расскажу, что такое JOIN в SQL, что такое Foreign Key, какой тип JOIN когда использовать - INNER или OUTER - и зачем вообще.

Каждая команда аналитики рано или поздно сталкивается с одной и той же проблемой: SQL-скрипты начинают жить своей жизнью, lineage оказывается неполным, ручные расчеты теряются в ноутбуках и Python-файлах, а любое изменение в базе данных превращается в потенциальную аварию. Мы долго искали инструмент, который позволил бы хранить данные как код, автоматически управлять зависимостями и при этом не требовал построения очередного сложного зоопарка из Airflow, dbt и десятка вспомогательных сервисов.

В этой статье я расскажу о нашем опыте внедрения SQLMesh поверх ClickHouse: как мы получили воспроизводимые расчеты, изолированные окружения для разработки, автоматический backfill, lineage для ручных отчетов через seeds и почему в некоторых сценариях SQLMesh оказался удобнее привычного dbt. Разберем реальные примеры моделей, окружений и практические кейсы, с которыми столкнулись в работе.

Полторы недели назад я выложил на Habr бота с лентой хороших новостей на sqlite-vec за $5/мес. Потом пришли живые юзеры — и началось самое интересное. Не код. Эксплуатация.

За 10 дней в проде:

🪦 Бот дважды умирал незаметно — поллил Telegram и казался живым, но не создавал ни одной новости по 4–5 дней. Один раз — OOM на загрузке модели, другой — feedparser.parse(url) без таймаута заморозил весь пайплайн.

📉 Метрика релевантности «рухнула» до 30% — и я чуть не откатил рабочую фичу. Оказалось, один юзер поставил 106 дизлайков из 228 и отравил и метрику, и приор источников. Починил, считая по уникальным юзерам — правда оказалась 42%.

🎯 Реакции 78 человек сами показали, какие источники выкинуть: tech-аудитория отвергает общие новости и любит курируемое.

Внутри — реальные логи, код фиксов (httpx-таймаут, watchdog, робастные метрики) и уроки про надёжность воркеров и доверие к цифрам.

👉 @futur_e_news_bot

В телеком-сети возник класс «тихих» деградаций: абоненты сообщали, что при отличном уровне сигнала невозможно совершить или принять голосовой вызов, при этом вендорский мониторинг не фиксировал аварий. С точки зрения метрик оборудование оставалось «зеленым», а проблема обнаруживалась только по пользовательским жалобам.

Задача сводилась к автоматическому выявлению таких инцидентов на десятках тысяч объектов сети, используя только исторические временные ряды в ClickHouse, без вынесения вычислений во внешние системы.

Сложность заключается в том, что поведение объектов существенно различается: для большинства базовых станций периодическое отсутствие трафика является нормой, поэтому фиксированные пороги либо дают ложные срабатывания, либо пропускают реальные инциденты.

В статье разбирается инженерный подход: построение индивидуальных исторических профилей нагрузки, медианные бейзлайны и детекция отклонений от ожидаемого поведения.

Показана реализация на SQL в ClickHouse с применением паттерна Islands & Gaps для выделения инцидентов во временных рядах.

Когда говорят «генератор миграций», обычно в голове сразу появляется что-то вроде:

Генератор миграций начинается не с CREATE TABLE, а с вопроса: как представить текущую схему базы в коде?

В первой статье серии разбираем PostgreSQL-first introspector: читаем таблицы, колонки, constraints и индексы, где хватает information_schema, а где приходится идти в pg_catalog, и собираем детерминированный snapshot схемы. Миграции пока не генерируем — строим фундамент, из которого потом можно будет сделать diff и получить DDL.

Статья будет полезна тем, кто пишет инструменты вокруг баз данных, интересуется PostgreSQL internals или хочет понять, почему автомигратор — это не просто набор ALTER TABLE.

В предыдущей части цикла разобрали 13 таблиц REDB: как устроены objects, values, structures, как RTTI-хранение значений отличается от старого EAV-паттерна, зачем нужен scheme_metadata_cache. Если не читали — начните с неё, без понимания схемы дальше тяжело.

В этой статье — то, что обычно идёт следующим вопросом: «А индексы где? У вас же значения всех полей лежат в одной таблице. Любой WHERE — это Seq Scan по миллионам строк».

Это статья 1.1, а не 2 — потому что она прямое продолжение разговора про физическое хранение. Глубокое погружение в C# — это статьи 3-5 цикла: Code-first схемы (SyncSchemeAsync<T>), CRUD (SaveAsync/LoadAsync), LINQ-транслятор. Здесь разговор остаётся в плоскости БД и DDL.

Цифры, на которые опираемся, — с реального прода: TSUM, логистическая система, обслуживает движение грузовиков и заказов через РЦ.

Шесть лет назад, в начале 2020 года, группа разработчиков оглянулась на Firebase и подумала: «А давайте сделаем то же самое, но открытым кодом и на SQL!» Так родился Supabase: проект с искренней целью дать разработчикам контроль над данными и избавить от проприетарных заморочек.

А с распространением Vibe Coding, когда нейросети удобнее работать с API, а не писать логику для СУБД, взлёт Supabase пошел по экспоненте.

varchar(255) выглядит как аккуратное ограничение и часто воспринимается как способ сэкономить место.
Но в PostgreSQL это не так: база хранит фактическую строку, а не заранее выделяет память под весь лимит.

Разбираемся, что на самом деле делает VARCHAR(N), чем он отличается от text, когда ограничение полезно, а когда просто превращается в число, которое притворяется архитектурой.

Каждый бэкенд-разработчик, который хоть раз готовился к собеседованию, слышал про аббревиатуру ACID. Какая-то часть из слышавших сможет её расшифровать. Какая-то часть из расшифровавших — объяснить, почему важен каждый из принципов, скрытых за этими четырьмя буквами. И уж точно каждый из этих замечательных разработчиков знает цену букве «I» — isolation, изоляции транзакций.

Те, кого заинтересовал заголовок, скорее всего, относятся к одной из трех категорий читателей:

Первые знакомы с этими понятиями в теории, но не имели шанса решать их на практике. Вам — обещание: когда вы столкнётесь с этими загадочными на первый взгляд явлениями в бою, вы уже будете к ним готовы. А если прочитаете статью до конца и вникнете во все примеры — сможете блеснуть на собеседовании знанием тонкостей борьбы с гонками в реальных highload-приложениях, даже не имея такой практики.

Вторые решали такие проблемы «на ощупь», не до конца понимая механику. Вам — собрать разрозненный опыт в систему: увидеть полную карту способов и понять, какой из них и почему обходится дороже.

Третьи сталкивались с этими проблемами и знают, как их решать. Вам — наглядная демонстрация цены тех решений, которые вам уже приходилось имплементировать: конкретные цифры, во сколько на самом деле обходится каждый подход.

В этом материале систематизируем способы бороться с race conditions в Postgres и считаем, во сколько обходится каждый.

Сравниваем нативный Property Graph в Spanner с рекурсивными CTE в AlloyDB — и объясняем, почему для персональной wiki второй подход оказался практичнее

Если вы работаете с базами данных и используете ORM, вы, вероятно, сталкивались с той же проблемой, что и я. ORM отлично подходят для отображения таблиц на объекты. Но они начинают мешать, когда запрос становится сложным: агрегации, тщательно продуманные JOIN’ы, формы отчетов, которые не соответствуют одной модели на таблицу. Вы боретесь с ORM, переходите на сырой SQL, а затем вручную пишете связующий код (маппинг).

Не каждый SELECT возвращает то, что подходит под одну ORM-модель. SQL - это лучший язык для доступа к данным. Лучшие ORM, которые я использовал, такие как Drizzle, побеждают, потому что они остаются близки к SQL. Я хотел пойти дальше: хранить SQL в системе контроля версий и генерировать из него типизированный Python.

Именно поэтому я создал nORM (no ORM - не ORM) и выпустил версию v0.1.0 на этой неделе (мой первый опенсорс проект).

У нас был долгий REFRESH MATERIALIZED VIEW: один запуск мог идти около часа, а повторные запуски вставали в очередь и держали соединения. CONCURRENTLY помогал не блокировать чтение из materialized view, но не решал проблему очереди одинаковых REFRESH.

Мы сделали механизм в PostgreSQL: триггерами отмечаем изменения в зависимых таблицах, храним зависимости каждой MV в служебной таблице, а перед обновлением берём pg_try_advisory_xact_lock по конкретной MV. Если lock не удалось взять — значит, обновление уже идёт, и второй REFRESH не ждёт в очереди, а пропускается.

Продолжаем серию «Адаптивное администрирование Sigla Vision». Разберем кейсы, где триггеры в базе FineDB помогают решать задачи администрирования Sigla Vision.

Привет, Хабр! Меня зовут Всеволод Коваленко. В Газпромбанке я занимаюсь развитием функционала BI-системы на базе Sigla Vision.

В предыдущей статье «Версионирование таблиц репозитория метаданных Sigla Vision» мы разобрали исторические таблицы, которые хранят данные о состояниях записей в БД. Версионирование таблиц мы тоже строили на триггерах FineDB. Теперь покажем, как те же триггеры решают еще ряд задач администрирования Sigla Vision.