Как убрать тормоза ORM на 80% с помощью грамотных индексов в PostgreSQL

Современные приложения часто плотно завязаны на ORM (Object-Relational Mapper) ради быстрой разработки. ORM реально ускоряют разработку, но при этом нередко генерируют запросы, которые не до конца оптимальны с точки зрения производительности базы. В такой ситуации у инженеров по БД мало контроля над тем, как именно выглядят запросы, поэтому индексация и тюнинг базы остаются главными инструментами для ускорения.

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

👉 @SQLPortal

Один чувак написал подробный разбор того, как базы данных на самом деле выполняют JOIN'ы.

В этом разборе он объясняет, какие алгоритмы работают под капотом, когда мы используем JOIN: nested loop join, hash join, merge join, index join, grace hash join и broadcast join, а также почему query planner выбирает один вариант вместо другого.

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

👉 @SQLPortal

Нужно быстро поднять PostgreSQL для MVP или pet-проекта?

В MWS Cloud Platform база данных PostgreSQL разворачивается за минуты и сразу готова к работе:

⏺️готовые конфигурации CPU и RAM под разные типы нагрузок
⏺️high availability или standalone конфигурации, автоматические бэкапы
⏺️гарантированные мощности CPU, консистентный API и удобный cloud-native IAM
⏺️сетевые или сверхбыстрые NVMe-диски под разные сценарии
⏺️постоянный primary endpoint: адрес не меняется при failover или switchover
⏺️до 3 read-only точек подключения — удобно для подключения аналитики
⏺️поддержка популярных расширений PostgreSQL "из коробки"

Подходит для любого проекта — от интернет-магазина до высоконагруженного backend-сервиса.

🆓 До 31 марта production-ready PostgreSQL в облаке — бесплатно

🔥 Запустите свой проект, протестируйте под нагрузкой и спокойно оставляйте базу в продакшене.

Попробовать бесплатно*

* Скидка 100% на оплату сервиса Managed PostgreSQL предоставляется в период с 9 февраля по 31 марта 2026 года для участников акции. Подробные условия — по ссылке

В PostgreSQL 19 (dev) прилетели еще 2 полезных изменения:

1. Разрешили ALTER COLUMN SET EXPRESSION для виртуальных столбцов с CHECK-ограничениями

2. Запретили CR и LF в именах баз данных, ролей и табличных пространств

Небольшие изменения, но оба коммита полезные:
- первый про более гибкую работу с virtual columns
- второй про ужесточение/санитизацию имен и снижение странных кейсов

👉 @SQLPortal

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

CREATE INDEX idx_orders_dt_only ON orders ((created_at::date)); 

SELECT count(*) FROM orders WHERE created_at::date = '2024-05-20';

👉 @SQLPortal

В Postgres 18 появился новый метод клонирования для создания баз данных из шаблонных (template) БД, который работает заметно быстрее, чем другие способы. Это работает на конкретных файловых системах, которые поддерживают copy-on-write / reflink.


👉 @SQLPortal

Какой SQL-запрос работает быстрее?

SELECT * FROM orders
WHERE status = 'NEW'
   OR status = 'PENDING'
   OR status = 'PROCESSING';

vs

SELECT * FROM orders
WHERE status IN ('NEW', 'PENDING', 'PROCESSING');

👉 @SQLPortal

Перестань переписывать JOIN через ON; используй USING

Если ты давно пишешь JOIN’ы в SQL, ты наверняка привык к ON. Оно работает и делает свою работу. Но когда ты джоинишь две таблицы по колонкам с абсолютно одинаковым именем, есть более чистый и аккуратный вариант: USING.

Вот почему стоит подумать о переходе.

SELECT 
       e.Employee_ID,
       e.Employee_Name, 
       e.Department, 
       s.Net_Sales
FROM Employees e 
JOIN sales s
ON e.Employee_ID = s.Employee_ID;

ON ок, но оно многословное. Приходится повторять и имена таблиц, и имена колонок. Если имя колонки одинаковое в обеих таблицах, ты по сути пишешь одно и то же дважды. Хуже того: когда выбираешь колонки, можешь получить два столбца Employee_ID, если явно не квалифицировать их.

USING это сокращение для join’ов по равенству, когда колонки называются одинаково. Та же самая выборка будет такой:

SELECT 
     e.Employee_ID,
     e.Employee_Name, 
     e.Department, 
     s.Net_Sales
FROM Employees e 
JOIN sales s
USING (Employee_ID);

Намного чище, да? USING автоматически сопоставляет колонки с одинаковым именем и делает inner join (или left/right join, в зависимости от типа join). Ты указываешь имя колонки один раз.

Перейти на USING это маленькое изменение, которое делает SQL короче и более “самодокументируемым”. Меньше шансов ошибиться, и результирующий набор получается аккуратнее. В следующий раз, когда джоинишь по одинаково названным колонкам, выкинь ON и попробуй USING. Только проверь, что твоя СУБД поддерживает USING.

👉 @SQLPortal

В Postgres есть unlogged-таблицы: для них отключается Write-Ahead Logging (WAL). За счёт этого запись становится заметно быстрее, но очевидная цена — такие таблицы не реплицируются через WAL и после крэша/перезапуска их содержимое не восстанавливается (по сути, данные считаются временными). В некоторых сценариях этот размен реально оправдан.

👉 @SQLPortal

Как выполнить поиск по нескольким условиям с помощью Xlookup

👉 @SQLPortal

JSONB-колонки Postgres и TOAST: гайд по производительности

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

Работа с API и массивами в типе jsonb в последнее время стала заметно популярнее, и хранить куски данных приложения в jsonb превратилось в распространённый паттерн.

Но зачем вообще “нарезать” JSON-объект на строки и колонки, а потом собирать его обратно, чтобы отправить клиенту?

Ответ: эффективность. Postgres быстрее всего работает со строками и колонками, а когда ты прячешь структуру данных внутрь JSON, движку сложнее разогнаться на максимум, как он мог бы.

👉 @SQLPortal

😒 Подборка каналов по информационной безопасности

Проверенные каналы по безопасности, которые реально помогают расти.

👍 ZeroDay — Уроки, эксплуатация уязвимостей с нуля
👍 Белый Хакер — Свежие новости из мира ИБ
😎 Бункер Хакера — Статьи, книги, шпаргалки и хакинг
👨‍💻 Серверная Админа — Настройка и уроки по компьютерным сетям

📂 Подписывайся

Полезные Excel формулы

👉 @SQLPortal

Краткая шпаргалка по SQL с примерами запросов

https://github.com/enochtangg/quick-SQL-cheatsheet

👉 @SQLPortal

Cтатья про ACID-свойства.

Не только теория, но и практическая реализация на PostgreSQL с примерами из реальной жизни.

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

👉 @SQLPortal

😢😢😢

👉 @SQLPortal

Поток данных в Postgres для чтения/записи:

Приложение --> (опционально) пулер --> отдельный backend/клиентское соединение --> shared buffers --> кэш ОС (page cache) --> физический диск.

При чтении к кэшу ОС или диску обращается только если нужных страниц нет в shared buffers.

👉 @SQLPortal