PostgreSQL *

Некоторые из IT-компаний говорят, что поддерживают open source. На деле это нередко означает использование чужого кода и PR-активность. Мы считаем, что настоящий вклад — это коммиты в ядро. И чтобы делать это системно, мы открыли инженерный центр не в столичном бизнес-парке, а в месте, где фундаментальная наука — часть культурного кода. Рассказываем, почему будущее системного программирования мы строим в новосибирском Академгородке.

Пополнение в списке контрибьюторов:

New PostgreSQL Contributors 2025

Major Contributors:

Андрей Бородин (Andrey Borodin, Яндекс.Облако, наши ПОЗДРАВЛЕНИЯ!
Якоб Чемпион (Jacob Champion, EDB),
Йелте Феннема-Нио (Jelte Fennema-Nio Motherduck, DuckDB),
Роберт Трит (Robert Treat pgtreats, за общественную деятельность).

Просто новые контрибьюторы:

Эндрю Кейн (Andrew Kane),
Энди Фэн (Andy Fan),
Ханс-Юрген Шёниг (Hans-Jürgen Schönig),
Хиан Хе (Jian He),
Марко Нанчиарини (Marco Nenciarini),
Майкл Голдберг (Michael Goldberg),
Сара Конвей (Sarah Conway).

Я построил полноценную образовательную платформу для изучения иврита — с интерактивными тренажерами, умным словарем на 4000+ слов и системой подписок. В статье рассказываю о нетривиальных технических решениях, архитектурных выборах и ошибках, которые пришлось исправлять по ходу.

Продукт: hebrewglot.com

Стек: Next.js 15, TypeScript, PostgreSQL + SQLite, Stripe, NextAuth

Вступление: Почему я вообще это пишу?

Представьте: нужно обновить базу данных размером с небольшое озеро — целых 10 ТБ. Классические методы тут не работают. Сделать дамп и восстановить? Это ж на неделю бизнес встанет. Обновлять «в лоб» с 11-й до 17-й версии? Это рискованно и надолго всё упадёт.

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

Пока я готовился, я наступил на все возможные грабли — от устаревших расширений до разницы в ОС. Чтобы вы не повторяли моих ошибок, я решил написать этот неформальный гайд. Здесь — только суровая практика, без воды и заумных терминов.

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

В этой статье рассмотрим, как использование PG_EXPECTO позволяет кардинально ускорить этот процесс. Мы не будем гадать на основе снимков pg_stat_statements. Вместо этого мы научимся проактивно создавать «ловушки» на проблемные паттерны производительности. Когда инцидент происходит, PG_EXPECTO позволяет быстро найти проблемные SQL-запросы , предоставляя инженеру готовый список «подозреваемых» для дальнейшей оптимизации.

Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic и GitHub

kznalp/PG_EXPECTO: Комплекс статистического анализа производительности СУБД PostgreSQL

pg-expecto/pg_expecto: Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

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

Давайте честно, поиск работы — это ад. Я инженер и я ненавижу рутину. А поиск работы — это 90% тупого кликанья.

Открыть 50 вкладок — 50 раз написать «Здравствуйте‑ меня заинтересовало...» — 50 раз скопировать‑вставить. Это выжигает.

Можно конечно написать автокликер, который будет спамить «пустышками». Но рекрутеры не дураки — такие отклики летят в мусор. А «ручной» режим‑ это 3–4 часа в день.

Я понял — что должен быть третий путь. Не просто автоматизация — а умная автоматизация.

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

Всем привет! Меня зовут Алексей Кременьков, я старший разработчик в Яндекс Почте. В этой статье расскажу, как мы работаем с большим количеством шардов PostgreSQL: как создавали собственный сервис динамического шардирования Sharpei, как развивали инфраструктуру под него и как проходил переезд на облачное решение. В конце разберёмся, какие плюсы и минусы мы смогли найти в этом решении.

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

Это не удивительно, так как select for update - очень популярный прием во всех СУБД, даже на Хабре есть статья на эту тему.

Привет, Хабр! Сегодня познакомимся с Кибер Бэкапом 18 — новой версией нашей системы резервного копирования. Релиз у нас получился «увесистый» — мы обеспечили дальнейший рост производительности и масштабируемости системы, защиту новых и развитие возможностей защиты уже поддерживаемых источников данных, реализовали открытый API управления планами защиты, выполнили доработки в части интерфейса и управления системой, а также выпустили ознакомительную MVP‑версию Кибер Медиасервера.

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

Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic

kznalp/PG_EXPECTO

Формулировка задачи:

Разработка специализированных конфигурационных файлов метрик для оценки производительности систем управления базами данных (СУБД) с использованием инструментария pg_expecto. Результаты работы предназначены для интеграции в системы мониторинга и обеспечения основ для реализации механизмов проактивного анализа производительности СУБД.

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

Поиск работы – это... боль. Нет- не так. Это – ад.

Это бесконечный скроллинг- десятки открытых вкладок.

Транзакции — не про «магическое ACID», а про конкретную механику согласованного доступа к данным под нагрузкой.

Эта статья объясняет как реально работают уровни изоляции и чем отличаются популярные СУБД на практике.

Мы разберём:

Можно ли смоделировать хаос пуассоновских потоков бронирований и конечный автомат состояний рейса (от «по расписанию» до «приземлился») целиком внутри PostgreSQL? Мы решили, что для создания идеальной учебной базы данных — можно. Вместо старых статичных таблиц мы построили генератор, имитирующий жизнь глобальной авиакомпании. Рассказываем, зачем это было нужно и почему старая база на 2,5 ГБ перестала справляться с задачами.

Один запрос выполняется 100 мс, другой — меньше 1 мс. Оба делают одно и то же, но второй написан на странном, почти алхимическом SQL. В чём подвох? Первый использует OR, а второй — хитрую комбинацию AND. Этот перевод — расследование того, почему условие OR так дорого обходится вашей базе данных, и практическое руководство по тому, как проектировать схемы, чтобы избежать этой ловушки производительности.

«Современная производительность — это сложный пазл, где метрики СУБД, дисковые операции, потребление CPU и сетевые задержки тесно переплетены. Традиционное нагрузочное тестирование часто дает лишь часть ответа, заставляя нас собирать данные из десятка разных источников. В этой статье мы рассмотрим, как расширение pg_expecto становится единым источником истины, объединяя метрики инфраструктуры и PostgreSQL в едином контексте. Узнайте, как превратить разрозненные данные в целостную картину и получить точный ответ на вопрос: где на самом деле кроется узкое место вашей системы?»

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

Думаю, у каждого, кто искал работу, есть этот "любимый" запрос на hh. Вбиваешь "Python Developer", ставишь фильтр "нет опыта", а тебе вываливается 500 вакансий "Senior Analyst", где в требованиях "базовое знание SQL, Python будет плюсом".

Ручной разбор этой каши убивает время и мотивацию. Мой друг Роман (он IT-рекрутер и карьерный консультант) постоянно рассказывает, как кандидаты выгорают еще до первого собеса именно на этом этапе.

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

Очередной чат, и к тому же на rust?! Да, yet another. И да, в этой статье не будет каких-то новых откровений системного программирования с написанием своего фреймворка для работы со сетью на уровне драйверов или других испытаний. Этот альманах про мой первый опыт в веб-разработке, который может быть полезен для других новичков, ведь тут мы затронем помимо злосчастного rust такие вещи, как devcontainer, REST API, идентификацию-аутентификацию-авторизацию, WebSockets, SSE, юнит и интеграционные тесты, некоторые паттерны, логирование и прочее.

В мире СУБД общепринятая догма гласит: «Индексы ускоряют запросы». Но что, если в погоне за производительностью мы создали себе проблему? В этой статье, на практике показан парадоксальный сценарий, при котором удаление первичного ключа у таблицы pgbench_branch и последующее увеличение стоимости запроса привели к впечатляющему росту общей производительности PostgreSQL под нагрузкой. Слепое следование правилам может быть опаснее их осознанного нарушения. СУБД не так просты, как может показаться.

Как вы думаете, сколько человек документирует продукты в Postgres Professional? 50? 100? А вот и нет — всего десять. Рассказываем, как команде техписателей удается управлять сотнями файлов, почему их работа — это квест, и как они успевают контрибьютить в ванильный PostgreSQL.