Продолжаем проводить конкурc SQL в рамках «IT-Планеты 2026». Как обычно во втором этапе участникам было предложено решить пять задач на чистом SQL. Перейдем к рассмотрению задач.
Привет, Хабр!
Чем больше растет инсталляция Zabbix, тем сложнее становится управлять ее конфигурацией. Особенно если речь идет не об одном сервере мониторинга, а о нескольких инсталляциях, десятках команд и сотнях инженеров, которым регулярно нужно что-то менять: пороги срабатывания, IP-адреса, триггеры, шаблоны или наборы метрик.
В какой-то момент мы столкнулись с тем, что прямой доступ к Zabbix оказался плохим решением: давать его всем нельзя, а проводить каждое изменение через команду мониторинга — долго. В результате мониторщики постепенно превратились в узкое горлышко в команде Сервисного центра, а история изменений конфигурации оказалась разбросана между встроенным аудитом Zabbix, заявками и переписками.
Тогда мы решили посмотреть на конфигурацию мониторинга как на отдельный объект управления и вынести ее в централизованную CMDB. Так появилась система, которая собирает конфигурацию из нескольких инсталляций Zabbix, предоставляет единый интерфейс для работы с настройками, поддерживает RFC-процессы, хранит историю изменений и позволяет откатывать их при необходимости.
В этой статье расскажем, как устроена архитектура решения и какие задачи нам удалось закрыть с его помощью.
Экран, в котором я живу 4 месяца. Не открываю IDE — всю god crm пишу внутри god crm.
Всё на скрине — строки одной postgres-таблицы. заметка, тикет, агент — одна сущность. поэтому заменило мне ноушн, обсидиан и мессенджер сразу.
Код открыт, mit: github.com/holetron/godcrm
Привет, Хабр! Я — Дмитрий Селищев, в компании «Синимекс» совмещаю роли руководителя подразделения и разработчика баз данных. В этом материале хочу поделиться историей о том, как простые, но не всегда очевидные приемы помогают кардинально ускорить 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 в прод не ставят.
Каждый раз, когда в компании возникают проблемы с производительностью PostgreSQL, обсуждение обычно идет по одному и тому же сценарию.
Сначала DBA оптимизируют запросы. Потом появляются новые индексы. Потом увеличивается размер серверов. Затем появляются реплики. Потом еще реплики. И через некоторое время выясняется, что значительная часть бюджета на инфраструктуру уходит на обслуживание системы, которая изначально должна была просто хранить данные.
Недавно мы в Tarantool столкнулись именно с такой ситуацией у одного из клиентов. В этой статье расскажем подробно об этой ситуации, поделимся, как мы ее решили и почему такой подход в целом стоит использовать практически всем, кто имеет дело с PostgreSQL.
Однажды я захотел узнать что-то новое по СУБД Postgres и структурировать уже имеющиеся знания. На помощь пришла программа сертификации. Рассказываю как подготовиться к прохождению теста от Posgres Professional и на что обратить внимание в первую очередь.
Мое имя Денис Непочитой, я уже несколько лет занимаюсь базами данных в ПСБ.
Администрировал разные системы, но в основном фокусе была АБС на Oracle (автоматизированная банковская система, «сердце» банка): от решения проблем с производительностью до обновлений на новую версию. В последнее время также сфокусирован на задачах по АБС, но уже на Postgres.
Для кого эта статья: для тех, кто только начинает свой путь в ИТ, и для всех, кто задумывается о прохождении сертификации.
Как это было — читайте ниже.
Всем привет!
Меня зовут Никита, я CEO компании VSL BI. Мы занимаемся внедрением BI-аналитики и автоматизацией отчетности для бизнеса.
Недавно к нам обратилась спортивная школа для детей.
Как и многие компании из сферы дополнительного образования, школа уже давно работала в Alfa CRM. Там велся учет клиентов, посещений, оплат, абонементов, тренеров и лидов. При этом данные были распределены по разным разделам системы. Для получения полной картины по бизнесу руководству приходилось собирать информацию вручную, формировать отдельные отчеты и сопоставлять показатели между собой.
Поэтому основной целью проекта стало создание единой системы аналитики, в которой данные из Alfa CRM автоматически собираются, обрабатываются и отображаются в виде дашбордов для руководства.
Новая статья из цикла про нашу OLTP-СУБД на Rust.
С самого начала мы выбрали MVCC на UNDO-логе вместо версионирования в heap, как в PostgreSQL. И годами повторяли свой же лозунг: «нет VACUUM, нет bloat». Оказалось, это правда ровно наполовину.
Heap и правда не пухнет от истории версий. Но bloat никуда не делся: он переехал в индексы, в мёртвые слоты и в сам UNDO-лог. А сборка мусора из одного механизма незаметно превратилась в пять, и мы только сводим их к единому координатору.
В статье разобрали без прикрас обе стороны. Что UNDO-модель дала: стабильный TID (UPDATE, который не трогает индексы), rollback пропорционально размеру транзакции, аналитику, не дорожающую от write-нагрузки, и AS OF как «машину времени» почти даром. И чем за это платим: главная эксплуатационная цена это долгоживущий снапшот, который молча останавливает очистку для всех.
Вопрос к тем, кто эксплуатировал MVCC-базы под нагрузкой: что меньшее зло — блокировать GC ради долгих транзакций или отдавать «snapshot too old»? Любопытно ваше мнение в комментариях.
Продолжаем рассказывать о том, как создали онлайн-платформу Playforma. Сегодня смотрим и разбираемся, что у нее внутри.
В первой части я ускорил большой интеграционный pytest-сьют с получаса до полутора минут за счёт инфраструктурных правок. Во второй проверяю следующий очевидный слой оптимизации — pytest-xdist.
Результат оказался не магическим, но полезным: -n auto дал ещё ×3.4 локально и около ×2.7 в CI. В статье показываю, почему xdist не заменяет дешёвый setup, а только домножает его; как разводить БД и Redis по воркерам; где упираются соединения Postgres; и почему память Docker VM и тюнинг Postgres не сдвинули потолок.
Про безопасные миграции написано уже тысячу раз. Мы все наизусть знаем и про expand/contract, и про обратную совместимость, и про то, что схему нельзя ломать под трафиком. А потом всё равно наступаем на эти грабли.
Вот свежий случай. Была задача на полчаса, надо было переименовать две перепутанные колонки. Прод целиком не лёг, но за одну выкатку я собрал сразу два инцидента. Причём один прилетел изнутри сервиса, а второй снаружи, оттуда, откуда я вообще не ждал.
Дальше расскажу, как так вышло
Когда у приложения появляется несколько хостов PostgreSQL, начинается головная боль: нужно динамически находить мастера после failover, выбирать реплику с нужным отставанием и гарантировать что пользователь не увидит устаревшие данные после своей же записи. DNS кешируется минутами, libpq не знает про lag, HAProxy не слышал про LSN. Разбираем как устроены существующие решения и как закрыть все три задачи через лёгкий HTTP сервис — pg-status.
Всем привет!
Ранее мы разбирались с одним конкретным примером - Supabase: как его поставить, зачем он нужен, какие есть аналоги и почему вокруг него в последнее время так много шума.
Но, мне кажется, что сейчас будет правильно сделать шаг назад и поговорить не про конкретный сервис, а про весь BaaS (Backend-as-a-Service). Как мы уже узнали из прошлой статьи, Supabase не возник сам по себе, до него был Firebase, а до Firebase были обычные самописные API, куча настроек авторизации, хранения файлов, нотификаций с вебсокетами и остального.
В этой статье мы разберем, что такое BaaS, почему он вообще понадобился, чем Firebase отличается от Supabase, для каких приложений такой подход подходит, а где уже нужен собственный backend.
JOIN - крайне популярная операция в SQL, о которой еще и спрашивают на 99% собеседований на программиста. Но когда начинаешь впервые разбираться с ней, то постоянно путаешься, какие таблицы соединять и когда именно.
В этой статье простыми словами и с великолепной графикой расскажу, что такое JOIN в SQL, что такое Foreign Key, какой тип JOIN когда использовать - INNER или OUTER - и зачем вообще.
Последнее время я всё чаще встречаю одну и ту же мысль: бизнес никогда не даст ИИ‑агенту доступ к базе клиентов, заявкам, платежам, CRM или внутренним документам. На первый взгляд звучит логично. Если агент ошибётся, перепутает контекст или выполнит не то действие, ущерб может быть вполне реальным. Но мне кажется, что здесь часто путают две разные вещи.
Давать агенту прямой доступ к базе действительно нельзя. А вот давать ему возможность работать через ограниченный, проверяемый и журналируемый контур действий вполне можно. Примерно так же мы не даём пользователю прямой доступ к PostgreSQL, но разрешаем ему нажимать кнопки в интерфейсе, которые вызывают заранее описанную бизнес‑логику.
В этой статье я хочу как раз таки разобрать, как может выглядеть такой контур на практике: без магии, без «агент всё сам решит», без сырого SQL от модели и без веры в то, что хороший prompt заменяет нормальную архитектуру.
Автономная диагностика СУБД требует от LLM-агента не просто генерации текста, а точной последовательности действий: сбора телеметрии, анализа планов запросов и блокировок. Мы провели эксперимент по оптимизации окружения ИИ-агента (Virtual DBA) для Postgres. Использовав механизм записи и ускоренного воспроизведения реальной нагрузки (record/replay), мы запустили эволюционный поиск по пространству параметров среды — от изменения промптов до перекомпоновки шагов анализа и MCP-инструментов. Результаты показывают, как автоматический выбор конфигурации влияет на качество диагностических выводов и почему избыток доступных инструментов может ухудшить итоговый вердикт.
Наверное не существует в мире технической поддержки, которая бы среди прочего не занималась спасением данных клиентов. Не минула участь сия и нас в Postgres Professional. Однако особенность спасения битых данных в СУБД заключается в том, что сломаться может сразу на двух уровнях: физическом и логическом. Первое, это когда что-то случилось с физическим файлом внутри которого лежат данные, а второе это когда файл цел, но внутри него каша без смысла. Поэтому сегодня мы поговорим о том как понять что в вашей базе что-то пошло не так, как понять почему, как оценить ущерб и минимизировать его. А в конце, бонусом, обсудим как не стать героем подобных статей.
PostgreSQL: PostgreSQL 19 Beta 1
Официальный релиз запланировали на сентябрь/октябрь. Вот что старейшины решили выделить в описании релиза 19-й версии:
Производительность
PostgreSQL 19 усовершенствует асинхронную подсистему ввода-вывода, представленную в PostgreSQL 18: io_method=worker теперь автоматически масштабирует количество рабочих процессов ввода-вывода на основе новых параметров io_min_workers и io_max_workers.
Расширение pg_plan_advice позволяет пользователям стабилизировать и контролировать решения планировщика, а pg_stash_advice - автоматически применять рекомендации, используя идентификаторы запросов.
Autovacuum теперь может использовать параллельные рабочие процессы, которые можно настраивать с помощью нового параметра autovacuum_max_parallel_workers, а новая система оценки autovacuum помогает расставлять приоритеты таблиц при их вакуумировании. Кроме того теперь PostgreSQL помечает страницы как видимые, когда их запрашивают.
Enterprise-разработка рано или поздно сталкивается с классической задачей: нужно выдать доступ к БД аналитикам, тестировщикам или саппорту в проде, но при этом необходимо скрыть персональные данные или коммерческую тайну. Статическое маскирование отлично подходит для случаев, когда таблица копируется полностью, но что если “замаскировать” нужно просто результат какого-либо запроса? Здесь пригодится маскирование динамическое, и в этой статье мы рассказываем об инструменте transp_anon, который входит в новый релиз СУБД Tantor Postgres 18.
