Каждому пользователю моего конструктора нужен свой Telegram‑бот. Рассказываю, как держать сотни ботов в одном процессе Node.js: общий webhook, очередь в PostgreSQL на SKIP LOCKED и Mini App на 5 КБ. С замерами нагрузки и честным разбором, где у схемы потолок.
Спор о формате таблиц для lakehouse, похоже, закончился, Iceberg сегодня поддерживают Trino, Spark, ClickHouse, Snowflake и дальше по списку, так что следующим приходится выбирать каталог. Каталог хранит указатель на актуальную версию таблицы, проводит commit и решает, кому эту таблицу читать, поэтому по весу я бы поставил этот выбор рядом с выбором СУБД.
В статье разбираю Lakekeeper, это один бинарник на Rust и обычный Postgres для метаданных, права на OpenFGA до отдельной таблицы и механизм ContractVerification, который может отклонить commit, если тот ломает контракт данных. Для сравнения рядом Apache Polaris, проект фонда Apache на Java с RBAC в два уровня и федерацией внешних каталогов.
В конце описан стек из банковского проекта (RustFS, Lakekeeper с Postgres, SeaTunnel, NiFi, Trino и ClickHouse), который развернули на своём железе за три дня и через три недели вывели в тестовую эксплуатацию.
24 сентября вышла PostgreSQL 19 Beta 4. До release candidate осталось совсем немного, и на этом этапе уже интереснее смотреть не на длинный список новых возможностей, а на те изменения, которые реально способны поменять повседневную работу backend-команды.
В релизе есть заметные вещи вроде REPACK, нового WAIT FOR LSN, параллельного autovacuum, репликации sequence и pg_plan_advice. Но почти у каждой из них есть важное «да, но». REPACK (CONCURRENTLY) не означает «VACUUM FULL без блокировок». WAIT FOR LSN не превращает асинхронную реплику в синхронную. Планировщик теперь можно подталкивать, но это не делает hint-ы хорошей идеей по умолчанию.
Именно поэтому вместо обзора «50 новых фич PostgreSQL 19» я выбрал пять изменений, которые стоит прогнать на собственном staging до GA. Не чтобы немедленно включить их в production, а чтобы заранее понять, какие старые костыли после обновления можно будет убрать, а где появятся новые точки контроля.
Считается, что если fsync включён в конфиге — данные в безопасности. На практике это не гарантия, а всего лишь надежда: вызов может быть проигнорирован драйвером, виртуализацией или самой ОС, а СУБД при этом честно подтвердит COMMIT клиенту. Разбираем, как через несколько независимых проверок — от системных вызовов до жёсткой перезагрузки тестового стенда — узнать, действительно ли ваш WAL долетает до диска, а не только до кэша операционной системы.
Разбираем интеграцию интернет-магазина с МойСкладом на собственном движке, Next.js и PostgreSQL, после переезда с InSales. Если ваш магазин живёт в связке с МойСкладом и вы собираетесь уходить с платформы, эти места стоит проверить до запуска. У нас они всплыли на живых заказах, и два самых неприятных нашли сотрудники заказчика, а не наши тесты.
Перенос каталога, заказов и адресов с InSales здесь не разбираем, это отдельная тема. Всё ниже про то, что начинается после: остатки, резервы, статусы и деньги в двух системах, которые должны показывать одно и то же.
У меня было объяснение, почему ora2pg теряет внешние ключи при переносе схемы в PostgreSQL. Я его опроверг, придумал новое и опроверг ещё раз. Настоящая причина оказалась в одной проверке exists() в Perl-коде, а чинится всё одной строкой в конфиге.
Резерв товара сгорал за пять минут вместо тридцати: приложение и база писали в одну таблицу время из разных поясов. Как это найти, почему стейдж молчал и зачем проверять таймзону при старте.
Как упростить управление целым парком из 800+ экземпляров СУБД на базе PostgreSQL? Можно доработать postgres_exporter, чтобы настроить получение метрик под себя. А если ещё проще? Мониторить связкой Grafana, Prometheus и кастомизированным postgres_exporter, а данные получать через ИИ‑отчёт, который будет агрегировать данные Prometheus через прямые PromQL‑запросы.
Но если и этого мало, то можно вообще поручить ИИ‑агенту типовые тикеты вроде очистки места на диске и плановой остановки БД.
Меня зовут Станислав Епишин, я из команды «R4C.Support.Всадники апокалипсиса» в СберТехе. Я уже писал, как мы дорабатывали postgres_exporter → pangolin_exporter, исправляя баг в расчёте длительности транзакций, и как внедряли связку Prometheus + Pipeliner + TaskTracker + GigaChat для автоматического создания тикетов.
В этой статье расскажу про R&D‑исследование для небольшой команды DBA, в котором мы тестировали гипотезу: получится ли собрать автономного агента, который сам будет обрабатывать тикеты: очищать дисковое пространство, выполнять VACUUM/ANALYZE и планировать остановки БД?
Здесь я описал инструкцию по созданию агента (с полным кодом и пояснениями) и развёрнутый реальный пример про автономный VACUUM/ANALYZE с обнаружением аномалий через LLM. Также покажу, как организовать ленту событий для мониторинга работы агента, и детально разберу, где и как в проекте используется LLM.
После прошлой статьи про Huge Pages мы получили несколько вопросов, в которых особо пытливые читатели возмущались отсутствием в статье реальных замеров «С HP» и «Без HP» и сравнением результатов. Материалов по этой теме в интернете крайне мало, а подобных замеров и подавно. Те же, что есть, все какие-то синтетические (в основном переводы зарубежных источников), оторванные от реальности, от работы информационных систем и, тем более, от 1С систем. Поэтому мы, как дотошные исследователи, решили закрыть этот гештальт и проверить всё самим.
База 1С:ERP размером 650 Гб. 74 секунды на поиск всех персональных данных. Маскирование прямо в дампе, без незащищенных копий. Четыре часа до готовой обезличенной копии. В статье все разбираю пошагово, с готовым мета-словарём, который можно взять для своей базы.
В прошлой статье о Dasha, описана версия 1.5.0. С тех пор вышли релизы с 1.5.1 по 1.8.1: в них появились рекомендации по индексам, страница ввода-вывода на pg_stat_io, проверки схемы и анализ логов с планами auto_explain, новые mcp tools.
Разбираю несколько инженерных решений из небольшого браузерного проекта: бинго на шахматных задачах Lichess без собственного сервера. Как получить одну и ту же карточку у всех игроков в один день с помощью детерминированного сида, почему запись из пула данных нельзя удалять (флаг retired), как записать правило «одна партия в день» частичными уникальными индексами и почему политик RLS в Supabase недостаточно: по умолчанию клиентским ролям выданы права, в том числе TRUNCATE, который RLS не проверяет.
В феврале этого года проект с красивым именем Polaris незаметно стал полноценным проектом фонда Apache. Новость прошла как-то мимо, ну стал и стал, мало ли. Между тем это одна из тех новостей, которые лет через пять, возможно, будут называть поворотной точкой. Потому что Polaris — это каталог. А каталог в мире Iceberg — то самое место, где на самом деле лежит власть над вашими данными.
Звучит громко, понимаю. Поясню, откуда такая уверенность.
Последние несколько лет хранилища данных строят по новой схеме: файлы лежат в объектном хранилище, поверх них открытый формат в виде метаданных, движки обработки живут отдельно в виде федеративного обработчика и ходят за данными. Схему назвали лейкхаусом (Data LakeHouse), а формат в ней почти везде один и тот же — Apache Iceberg. Вендоры за него отвоевались, открыли и согласовали, и все выдохнули. Данные наконец-то ничьи (формат parquet): лежат у вас, читаются чем угодно, никакой платформы-хозяина.
Выдохнули рано. Зависимость от вендора никуда не делась, она переехала на другой уровень — в каталог. Сервис с виду лаконичный, держит одну-единственную вещь, указатель на актуальную версию таблицы. Заодно через него идут права доступа и временные ключи от хранилища. Получается, кто держит каталог, тот и решает, какие движки увидят ваши данные, а какие останутся снаружи.
Начнём даже не с каталогов, а на шаг раньше — с того, что такое вообще Iceberg, вокруг которого последний год прыгают все вендоры.
Обе мои предыдущие статьи про этот сайт с кейсами CS2 заканчивались списком того, чего в нём нет: платежей, депозита предметов, кейс-баттлов, рефералки, KYC. Список закрыт — и почти всё сложное в нём свелось к одному вопросу: что происходит, когда несколько человек одновременно двигают одни и те же деньги. Батл на четверых в одной транзакции, порядок блокировок, из-за которого не случается дедлок, PgBouncer под Prisma и правило чтения с реплики, которое нельзя выразить типом.
Задача звучала просто: посчитать, у скольких товаров в базе есть в составе хоть одна Е-добавка. Я думал, это работа на полчаса. Работа заняла вечер, и большая часть вечера ушла на одну букву.
Пользователь нажал кнопку, сеть пропала, а браузер не знает, дошёл ли запрос до сервера. Повторите запрос — можно получить дубль. Не повторяйте — потеряете действие.
Показываю схему, которая решает обе проблемы: API без toggle, ключ идемпотентности в PostgreSQL, очередь в IndexedDB, Service Worker и проверка офлайна в Playwright. Это не полный offline-first — только защита действий в момент обрыва связи.
SQL‑инъекция через декомпиляцию: от JAR‑файла до захвата пароля
Материал носит образовательный характер. Все работы велись легально, в рамках пентеста, с письменного согласия владельца системы и в изолированном контуре. Название клиента и продукта не раскрываем — NDA. Имена классов, пакетов и таблиц в листингах изменены. Применяйте это только на системах, доступ к которым у вас есть. Доступ к чужим системам без разрешения преследуется по закону.
Корпоративная Java‑система: складской учет, веб‑интерфейс, HTTPS. Внутри — SQL‑инъекция без аутентификации в одном GET‑запросе, из‑за строки «... WHERE ID=» + параметр.
Разберем, как найти такую в приложении без исходников: декомпиляция JAR → чтение сервлетов → уязвимая строка → подтверждение через pg_sleep. Каждый шаг воспроизводим.
Если посмотреть на самые обсуждаемые публикации Go‑сообщества последних месяцев, можно заметить любопытную закономерность. Среди них почти нет материалов про новые конструкции языка, generics или очередные изменения синтаксиса.
Зато много статей про диагностику утечек горутин, профилирование памяти, внутреннее устройство рантайма, особенности современных процессоров и эксплуатацию высоконагруженных PostgreSQL‑кластеров.
В 2026 году экосистема Go значительно «повзрослела». Сама спецификация языка уже стабилизировалась, и фокус инженерного внимания сместился в сторону эксплуатации (Production Engineering) — предсказуемости памяти, автоматической диагностики рантайма, управлению ресурсами железа и устойчивости баз данных под высокой нагрузкой.
На связи команда Golang‑инженеров Авито, а ниже — несколько публикаций, которые хорошо показывают этот сдвиг.
Представь очередь. В ней все, кто когда-либо жил на Земле — от первого человека до ребёнка, родившегося минуту назад. Очередь длиной примерно в сто семнадцать миллиардов. Где-то в ней стоишь ты. Место у тебя есть с рождения, его никто не отнимет и не отдаст другому. Просто до сих пор никто его не называл.
Как посчитать порядковый номер человека по дате рождения, почему таблица из пятидесяти точек честнее плавной кривой, и как заставить Postgres держать анонимность ответов конструкцией, а не политикой — с одной дырой, которую я нашёл у себя сам.
Как открыть транзакцию на уровне use case, передать её репозиториям без зависимости бизнес-логики от ORM и правильно обработать вложенные вызовы.
