PostgreSQL *

Сессионные вычислители — залог успеха аналитики будущего

Всем привет, меня зовут Николай Голов. azathot Всю свою профессиональную жизнь я строю аналитические платформы. Возможно, вы видели мои статьи про Vertica и Snowflake.

[ Vertica+Anchor Modeling = запусти рост своей грибницы (Avito блог??, перед?? ней HP Vertica, проектирование хранилища данных, больших данных ]

- статья, 27 февраля

наша дискуссия с новой командой начиналась с одного и того же «дня сурка»:

— бизнес: «Аналитики работают слишком медленно!»;
— аналитики: «Нам не дают работать с базой напрямую, заставляют ставить задачи дата-инженерам и ждать неделями!»;
— инженеры: «Да как их пустить в центральное DWH? Вы видели их запросы? Один забытый ON в джойне — и база ложится на бок, блокируя и отчеты для CEO, и критические ETL-процессы».

Этот сюжет я наблюдал везде: в классическом on-premise (Greenplum, Vertica), в модных китайских решениях (StarRocks) и даже в open-source Lakehouse-инсталляциях (Spark). Меня окончательно шокировал кейс одной огромной европейской компании по доставке еды: она сидела на Databricks, имела практически неограниченные ресурсы, но всё равно страдала от взаимных блокировок и конкуренции за ресурсы.

Как должна выглядеть база, в которой аналитикам действительно можно дать полную свободу? Представьте: каждый аналитик работает в своей персональной базе данных. Он видит актуальные данные в реальном времени, но физически не делит «железо» с соседом.

Фантастика? Нет, Snowflake первым доказал, что это возможно, внедрив архитектуру Multi-cluster Shared Data:

8 июля у PostgreSQL юбилей — ей исполняется 30 лет. В 1996 году Марк Фурнье из компании Networking Services предоставил первый внешний сервер для разработки опенсорсного проекта Postgres. До этого СУБД разрабатывали на мощностях Калифорнийского университета в Беркли .

В день рожденья PostgreSQL мы публикуем перевод статьи, которая послужила основой СУБД. Кстати, у неё тоже юбилей — 40 лет с момента выхода.

«Отдельные базы больше не нужны», «конец пайплайнов» - каждую неделю кто-то крупный со сцены хоронит то, что ты вчера поставил в прод. ClickHouse поступил ровно наоборот, и поэтому его анонсы стоит прочитать внимательно. Что реально показали на Open House 2026 и что из этого доедет до прода - разбор практика без вендорского глянца.

Я давно хотел убрать из backend‑разработки одну особенно липкую рутину: когда для каждой новой сущности снова и снова приходится собирать одни и те же слои REST API — repository, service, handlers, request/response модели, OpenAPI, auth, тесты, curl‑примеры, Docker и прочую инфраструктуру.

В этой статье рассказываю про query‑first подход и open‑source Go CLI rest, который позволяет реализовать эту идею. Смысл простой: если SQL‑запросы или MongoDB‑контракты уже описывают, какие операции нужны приложению, то из них можно сгенерировать согласованный каркас REST‑сервиса.

В статье показано, как это работает для PostgreSQL и MongoDB, что именно генерируется, что такоеrest doctor и почему цель инструмента — не заменить бизнес‑логику, а снять первые 80–90% повторяющейся ручной работы.

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

Рассмотрим пример с одной таблицей, имеющей один столбец с уникальным ограничением (и индексом):

Компания Postgres Professional представляет новое издание книги Егора Рогова «PostgreSQL 18 изнутри», которое будет выпущено в издательстве «ДМК Пресс» в 2026 году. Электронная версия доступна уже сейчас. Эта книга — подробный путеводитель по внутреннему устройству СУБД PostgreSQL, призванный помочь разработчикам и администраторам детально разобраться в механизмах её работы.

В данной статье я хотел бы поговорить немного о неявном приведении типов в Postgres, широко известно, что Postgres не позволяет неявно приводить строковые типы к числовым (как это делает Oracle) и эта добавочная строгость скорее всего правильна (избавляет от многих плавающих ошибок времени исполнения), но кое-какое неявное приведение типов всё-таки остаётся - это приведение внутри числовых типов (int2, int4, int8, numeric) и вот здесь возможны некоторые сюрпризы.

Давайте рассмотрим некий синтетический пример

Вы храните в PostgreSQL пользователей, заказы и платежи — а потом проект обрастает Redis для очереди, отдельным поисковиком и самодельными блокировками через таблицу locks. Иногда это оправдано. Но часто типовые бэкенд-задачи закрываются прямо в базе: атомарно, транзакционно, с индексами и без лишней сетевой болтовни.

Привет, Хабр! Меня зовут Тимур Исламгулов. Я преподаватель МФТИ и ведущий вебинаров по PostgreSQL. За годы работы я насмотрелся, как разработчики поднимают лишнюю инфраструктуру там, где хватило бы самой базы, — об этом и поговорим.

Недавно я изучал вопрос, насколько распространены полиморфные ссылки в реляционных базах — болезненном для производительности паттерне с дискриминированным внешним ключом, который автоматически генерируют ORM-фреймворки (Rails, Django, Hibernate), CRM-платформы (Salesforce) и 1С. Главная страница типичного интернет-магазина или activity-лента CRM-системы строится именно таким запросом: базовая таблица соединяется LEFT JOIN-ами со всеми возможными подтипами через пару столбцов (type, id).

Та статья отвечала на вопрос «насколько распространён подобный паттерн». Ведь если заниматься улучшением, то неплохо понимать, насколько оно полезно, не так ли? Здесь я пытаюсь дать представление о том, каким образом данный шаблон приводит к регрессии производительности и показать направления улучшения оптимизатора PostgreSQL, позволяющие облегчить ситуацию.

Спойлер: пока немного — но кое-что движется на pgsql-hackers. Три патча, обсуждавшихся в 2024–2026 годах, нацелены на три разных источника регрессии. Ниже о каждом.

Почему мы отказались от «AI в каждой кнопке» и зато встроили AES-GCM в детское приложение

Откуда вообще взялось MIO

MIO — это история про собственные родительские потребности, с которыми сталкиваешься, когда ребёнку исполняется 5 лет.

Family Vault - Ключи и envelope - E2E и что внутри

Наш осознанный шаг к безопасности. Для всех, без подписки и дополнительных оплат. Мы не говорим про конкурентное преимущество — мы говорим о важности оставаться уверенным, что твои данные не утекут.

Что происходит под капотом корпоративного мессенджера, когда нагрузка пробивает отметку в 650 000 запросов в секунду? Обычно в этот момент архитектура распределённых хранилищ начинает проверять на прочность не только диски и сеть, но и нервы команды эксплуатации.

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

AngaraBase — OLTP/HTAP СУБД, написанная с нуля на Rust. Совместима с PostgreSQL по протоколу — работает с psql, JDBC, psycopg2 и стандартными драйверами. UNDO-log MVCC без VACUUM, векторизованный исполнитель с SIMD-батчами — транзакции и аналитика под одним SQL и одним снапшотом, без ETL и второго хранилища. Fail-closed контракты ресурсов, USDT-пробы без рестарта, EXPLAIN с разбивкой по фазам исполнения. Dev preview доступен на angarabase.dev.

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

В этой статье я разберу проблему по слоям: откуда физически берётся расхождение, какие есть уровни решений (от коробки до event-driven на Go), и почему модный ответ «поставьте Kafka» для одного селлера почти всегда оверкилл. Будет код и будут цифры.

Разбираем мажорное обновление Greengage с версии 6 на 7: как работает pg_upgrade, какие шаги нужны для обновления кластера, чем помогает ggupgrade и какой выигрыш по времени дают копирование файлов и режим жестких ссылок.

Привет, Хабр! Пишет эту статью Александра Лысенко — вчера я была студенткой, а сегодня как инженер-программист Nexign спешу поделиться приобретенным опытом.

Мой первый проект для реального бизнеса был связан с миграцией с Oracle на PostgreSQL. Сегодня расскажу, как внедрение диапазонного типа данных при переходе между СУБД позволило не просто сохранить производительность, но и превзойти исходные показатели. Если вы тоже только начинаете свой карьерный путь — надеюсь, этот материал вам поможет.

В статье рассматривается shrink кластера Greengage DB с использованием ggrebalance: архитектура утилиты, FSM-подход, безопасное перераспределение данных через INSERT, сравнение с CTAS, поддержка rollback и результаты тестов производительности.

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

Тогда почему мы всё ещё тратим время, ходим на youtube и новостные сайты в поисках интересного контента? Зачем полагаемся на чей-то алгоритм - ведь тот же Claude хранит в том или ином виде историю переписки и таким образом может оценить наши реальные интересы. Может быть стоит взять в свои руки формирование 'информационного пузыря'?

Что важнее при выборе СУБД: выручка разработчика или реальные возможности продукта?

На российском рынке долгое время ответ фактически сводился к рейтингам продаж. Но ситуация постепенно меняется. Исследование ЛАНИТ стало одной из первых попыток сравнить отечественные СУБД не по финансовым показателям, а по техническим характеристикам — от совместимости и миграции до безопасности и администрирования.

Однако при внимательном изучении результатов возникли вопросы ....

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

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

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

Проект был разбит на множество микросервисов, каждый из которых хранил данные в собственной PostgreSQL-базе. Чтобы строить сквозные отчеты, информацию нужно было где-то объединять.

На тот момент аналитика уже работала через ETL: раз в сутки Airflow восстанавливал общую PostgreSQL из ежедневных бекапов, а Redash выполнял запросы уже к ней. Решение было надежным и не требовало нагрузки на production, но для real-time оно не годилось — в лучшем случае отчеты показывали состояние системы на начало дня.