PostgreSQL *

Меня зовут Евгений Ефимкин, я руковожу группой Platform Reliability в Yandex Cloud. В числе прочего мы занимаемся безопасностью наших managed‑сервисов.

В managed PostgreSQL мы не выдаём клиенту привилегии superuser — иначе он сможет выйти за пределы своей базы прямо в операционную систему. Чтобы клиент при этом мог выполнять привилегированные операции: создавать базы, заводить роли, менять настройки кластера, — мы пишем сервисы Control Plane и выдаём специальные ограниченные роли (без выхода в ОС и без обхода проверок прав).

Несколько лет назад, занимаясь поддержкой логической репликации, я понял, что и этого мало: у PostgreSQL остаются места, где он сам, изнутри, выполняет код от superuser в обход всей конструкции. Дальше — два случая повышения привилегий у двух разных публичных облачных провайдеров. Оба вектора к моменту публикации закрыты — и в апстриме PostgreSQL, и у самих сервисов; оба провайдера своевременно проинформированы.

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

В данной статье будет описана структура PostgreSQL-базы данных и реализация данной задачи с помощью SQL в варианте PL/pgSQL. Реализация на Apache Spark будет описана в следующей статье.

В качестве примера будут созданы настройки распределения и входные данные для:

Разработчики не экстрасенсы: как мы перестали приносить им туман вместо ТЗ

Кейс про вагоны, Claude и то, зачем аналитику иногда полезно «потрогать» будущую систему до разработки.

Рабочая история команды аналитиков о том, как бизнес-фраза превращается в инженерный материал.

В реальных проектах PostgreSQL часто работает не на полную мощность из-за дефолтных настроек, которые не учитывают специфику нагрузки. Разберём 5 неочевидных параметров, которые стоит подкрутить в postgresql.conf для стабильной работы в продакшене.

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

HTAP — одна из главных тем в мире СУБД. Вокруг PostgreSQL массово появляются конструкции с внешними аналитическими движками со своими моделями хранения данных и ограничениями совместимости, однако бизнесу не совсем комфортно жить в архитектуре, где транзакционные данные находятся в одной системе, аналитика — в другой, а между ними — разного рода ETL, CDC и прочие parquet‑файлы.

В Tantor мы движемся по иному пути, развивая HTAP внутри PostgreSQL, а не рядом с ним. Вокруг этой идеи строятся СУБД Tantor Polar и машина баз данных Tantor XData Gen3, в которой OLTP и аналитика, не теряя совместимости с Postgres, работают поверх общего хранилища данных и общей видимости транзакций. В этой статье хочется поговорить не столько о самом термине HTAP, сколько о том, как меняется архитектура PostgreSQL, когда OLTP и аналитика начинают работать поверх общего хранилища данных.

Практический разбор: запускаем PostgreSQL в Kubernetes с высокой доступностью, автоматическим failover и декларативным управлением - через один YAML-файл.

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

В статье разбираем, почему инвалидация кэша — это архитектурная проблема, как TTL, события, CDC и lease‑подходы влияют на консистентность и когда кэш лучше вообще не использовать.

LEFT JOIN считается одной из самых безопасных конструкций в SQL — пока один фильтр в WHERE тихо не превращает его в INNER JOIN. Ошибка коварная: запрос выглядит абсолютно нормальным, результаты приходят, база не ругается, а часть строк уже исчезла.

В статье разбираем, почему это происходит, как NULL ломает ожидания и чем на самом деле отличаются условия в ON и WHERE.

Один из первых сюрпризов при переходе с MS SQL на PostgreSQL состоит в отсутствии профайлера. Нет ни инструмента, ни аналога. Можно было бы поставить задачу команде разработки, но я решил попробовать поступить иначе, и за сутки, не написав ни строчки кода вручную, собрал работающий MVP с помощью ИИ. Рассказываю, как это было.

Я аквариумист. Однажды мне надоело гуглить совместимость рыб в десяти вкладках и записывать параметры воды в блокнот. За два месяца это вылилось в платформу с маркетплейсом, аукционами, AI-диагностикой и 93 таблицами в PostgreSQL. Рассказываю, что получилось, на чём построено и

В обсуждении под статьями «СУБД Tantor Postgres 18: обзор улучшений для 1С» и «В погоне за APDEX‑ом, или как создать HighLoad на недорогом серверном железе» чрезвычайно уважаемые люди задались вопросом про *_collapse_limit и его отношение к geqo_threshold. В сообществе обсуждали эти параметры в большом топике, в этой статье коротко описано то, к чему там пришли.

Число 20 взялось из поста Роберта Хааса 2009 года по то, можно ли что‑то сделать с параметрами *_collapse_limit в PostgreSQL версии 8.5, которая в то время выходила.

Официальное предупреждение (дисклеймер)

Настоящая статья подготовлена с использованием технологий искусственного интеллекта.

В частности:

— экспериментальные данные обработаны и проанализированы нейросетью;

— иллюстративный материал, сопутствующие слоганы, а также предисловие и послесловие сгенерированы нейросетью;

— макет статьи редактировался и корректировался нейросетью.

Лицам, придерживающимся позиции «ИИ‑веганства» (испытывающим устойчивый страх, неприязнь или психологический дискомфорт по отношению к нейросетевым системам), настоятельно не рекомендуется ознакомление с содержанием данной публикации, равно как и участие в её обсуждении, во избежание возможного нанесения вреда психологическому благополучию.

// todo: тут N+1 на invoice — надо переделать через entity graph.

Этот комментарий висел в коде полтора года. Все, кто заходил в файл, его видели. Никто не завёл тикет. В пятницу вечером он сработал — и забрал с собой три пода, 30% запросов на критичной ручке и моё спокойствие на выходные.

Каждый разработчик помнит тот самый момент, когда система, которая только что работала идеально, вдруг начинает вести себя так, будто сошла с ума. Когда дашборд в Grafana показывает что-то страшное, а ты стоишь перед ним с кружкой остывшего кофе и не понимаешь, с чего начать.

На нашем мероприятии Avito Go Loto разработчики поделились своим опытом без прикрас. О блоате в полтора терабайта, о девяти инстансах, которые передрались за один звонок, о бэкенд-разработчице, которая в пятницу вечером открыла чужой фронтовый проект, о нагрузочных тестах за несколько месяцев до большой рекламной кампании, и о транзакции, которую забыли закоммитить тоже в пятницу вечером.

Спойлер: все выжили. Но стали другими людьми.

Сначала всё выглядело как типичная AI-история успеха.

За пару вечеров LLM помогла превратить Google Sheets для учёта финансов в настоящее приложение. Потом появился backend, sync между устройствами, mobile-first UX, AI-рекомендации, rollback, conflict resolution, миграции, Docker images, golden tests и React-компонент на 10 537 строк.

Оказалось, что AI действительно радикально ускоряет старт разработки. Но production начинается сильно позже демки.

Лучший инструмент 1С эксперта по технологическим вопросам это голова. Подготовка к 1С:Эксперту по технологическим вопросам. Основной курс©

Удар был нанесен тупым предметом, очевидно головой (из милицейского протокола) ©

Из тех кто не собирается стать тимлидом (а возможно и из них тоже) 1С-ники делятся на тех кто собирается идти на экзамен 1С:Эксперт по технологическим вопросам и те кто собирается идти еще раз на экзамен 1С:Эксперт по технологическим вопросам.
Тем из них, кто в очередной раз поклялся за лето/отпуск переделать домашки курса

В SQL самые опасные ошибки часто выглядят как рабочие запросы. Они не падают, не ругаются на синтаксис и не подсвечиваются в IDE — просто возвращают пустоту там, где должны быть данные.

В этой статье разберём классическую ловушку NOT IN: почему один NULL в подзапросе может «отравить» всю выборку, чем IN на самом деле отличается от NOT IN и почему в таких случаях безопаснее писать через NOT EXISTS.

Провести честный тест на 30 000 ВРМ, сжечь 400 тысяч процессорных ядер-часов и доказать, что отечественная связка из RED OS, 1С и Postgres Pro Enterprise способна стабильно держать промышленную нагрузку в 1 Тб — выполнено. Рассказываем историю одного большого нагрузочного тестирования длиною в три месяца

Оператор OUTER JOIN — бич конфигураций 1С на базе PostgreSQL: планировщик пока небогат на оптимизации такого типа соединений. В то же время ORM-фреймворки — и 1С как яркий их представитель — часто генерируют внешние соединения по типовым шаблонам, что открывает возможности для точечной оптимизации.

В этой статье я разбираюсь с одним из таких шаблонов — разрешением полиморфных ссылок: что это за паттерн, откуда он берётся (Rails, Django, Hibernate, Salesforce — не только 1С), насколько он распространён и почему его структурные особенности позволяют существенно ускорить выполнение.

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

SUM() OVER (ORDER BY ...) часто выглядит как очевидный способ посчитать нарастающий итог, пока в данных не появляются одинаковые значения ключа сортировки. В этот момент результат начинает «прыгать», LAST_VALUE возвращает текущую строку, а запрос формально остаётся корректным.

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