PostgreSQL испытывает трудности при росте числа подключений

Даже умеренное количество клиентов может «сломать» PostgreSQL. Причина в том, как СУБД обрабатывает каждое соединение.

При подключении нового клиента процесс postmaster создаёт отдельный бэкенд-процесс (не поток) для работы с сессией. Этот процесс поддерживает соединение до отключения клиента или потери соединения.

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

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

Интересный факт, существует предложение перевести PostgreSQL на многопоточную модель вместо текущей многопроцессной, что потенциально могло бы решить проблему масштабируемости.

Детальный разбор того, как PostgreSQL управляет соединениями

👉 @SQLPortal

Новости: Выпущен PostgreSQL 18!

https://www.postgresql.org/about/news/postgresql-18-released-3142/

👉 @SQLPortal

Создавайте blockchain-таблицы в Oracle Database с помощью

CREATE BLOCKCHAIN TABLE ... ( ... )
NO DROP UNTIL n DAYS IDLE
NO DELETE UNTIL n DAYS AFTER INSERT
HASHING USING SHA2_512 VERSION "v1"

Эти параметры:

- разрешают INSERT,
- запрещают UPDATE,
- запрещают DELETE/DROP до истечения заданного количества дней (N).

👉 @SQLPortal

На GitHub появился новый проект SQLBot — база данных без SQL. 😱

Всего за несколько дней он собрал 1.5K ★

SQLBot умеет отвечать на вопросы на естественном языке, поддерживает MySQL, SQL Server, ClickHouse, RedShift и даже Excel/CSV.

Встроена авто-визуализация, прогнозы и простая установка через Docker.

SQLBot на GitHub

👉 @SQLPortal

Индексирование полнотекстового поиска с подстановочными символами в Postgres? Вот практическое видео, которое показывает, как использовать pg_trgm и GIN-индексы

👉 @SQLPortal

Бесплатный курс по SQL от Baraa Khatib Salkini, известного как DataWithBaraa. Курс охватывает всё от основ до сложных запросов и реальных проектов. 🤑

В GitHub-репозитории есть datasets/ с реальными данными из ERP и CRM, scripts/ с готовыми SQL-скриптами для практики и docs/ с документацией и материалами курса.

Ссылка на курс

👉 @SQLPortal

Совет для Postgres: используйте jsonb_pretty, чтобы выводить JSON в удобочитаемом вертикальном виде.

👉 @SQLPortal

Типы связей в базах данных:

Связи показывают, как данные между собой связаны.

Три основных типа связей:

Один к одному (One-to-One) —> запись в одной таблице связана с одной записью в другой таблице.

Один ко многим (One-to-Many) —> запись в одной таблице связана с несколькими записями в другой таблице.

Многие ко многим (Many-to-Many) —> записи в обеих таблицах могут быть связаны с несколькими записями в другой таблице.

👉 @SQLPortal

Простое объяснение Primary Key и Foreign Key в SQL:

Primary Key (PK) это уникальный идентификатор записи в таблице. В таблице customers поле customer_id является первичным ключом. Каждому клиенту присваивается уникальный номер, и два клиента не могут иметь одинаковый ID. Sarah Johnson всегда будет клиентом с ID 1001, а если завтра зарегистрируется другая Sarah Johnson, ей дадут другой ID. Это помогает организовать данные и избежать путаницы.

Foreign Key (FK) это связь между таблицами, как мост. В таблице orders поле customer_id является внешним ключом. Здесь он не уникален, потому что один клиент может сделать несколько заказов. Например, Sarah (customer 1001) сделала два заказа — на ноутбук и на клавиатуру. Внешний ключ customer_id в таблице orders ссылается на первичный ключ в таблице customers.

Без внешнего ключа пришлось бы хранить имя и email Сары в каждой записи заказа, что создаёт хаос и занимает лишнее место. Используя FK, данные клиента хранятся один раз в таблице customers, а в таблице orders просто ссылаются на него через ID. Это делает систему чистой, эффективной и масштабируемой.

PK уникально идентифицирует запись, а FK соединяет связанные данные между таблицами.

👉 @SQLPortal

В Postgres 18 появились виртуальные вычисляемые колонки

Если убрать ключевое слово stored в определении, колонка не будет храниться на диске, а будет вычисляться на лету.

Это экономит место и не замедляет записи, но может замедлять чтение, так что использовать стоит с умом.

👉 @SQLPortal

Получение значений из первой, N-й и последней строки:

FIRST_VALUE ⇒ первая
NTH_VALUE ⇒ N-я
LAST_VALUE ⇒ последняя

По умолчанию окно заканчивается на текущей строке ⇒

NTH_VALUE(v, N) возвращает NULL для строк до N
LAST_VALUE возвращает последнее значение с тем же sort key, а не из самой последней строки

👉 @SQLPortal

Карен Джекс поделилась свежим материалом о партиционировании в Postgres.

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

https://karenjex.blogspot.com/2025/09/postgres-partitioning-best-practices.html

👉 @SQLPortal

Pro-tip по дизайну БД: Soft Deletes

Soft delete — вместо того чтобы физически удалять строку, мы помечаем её как удалённую (например, deleted_at TIMESTAMP).

Плюсы:
- удобно для undo (отката);
- хранение истории ;
- не ломаются внешние ключи.

Но! 🚬

Если напрямую писать запросы к таблице, половина кода будет забывать исключать «удалённые» строки. В итоге поведение приложения становится непредсказуемым и разъезжается в разных местах.

Решение

Всегда создавай view, которое сразу фильтрует «живые» строки.

CREATE VIEW users_active AS
SELECT * FROM users WHERE deleted_at IS NULL;

Разработчики по умолчанию работают именно с view, а к базовой таблице обращаются только когда реально нужны «удалённые» данные.

Делай «безопасный путь» простым и привычным.

👉 @SQLPortal

Автоматизируйте задачи в Postgres с помощью pg_cron. Этот инструмент позволяет по расписанию запускать простые задачи, например VACUUM или пересборку материализованных представлений.

👉 @SQLPortal

Чтобы кешировать результаты вызовов функций в PL/SQL, объявляйте их с модификаторами:

DETERMINISTIC ⇒ кеширование в пределах одного SQL-выражения

RESULT_CACHE ⇒ кеширование между сессиями

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

https://mikesmithers.wordpress.com/2022/10/16/deterministic-and-result_cache-pl-sql-functions/

👉 @SQLPortal

Совет по Postgres для тестирования расширений:

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

LOAD 'auto_explain';
LOAD 'pg_stat_statements';

👉 @SQLPortal

Индексируйте скалярные значения в массивах JSON, хранящихся в Oracle Database, с помощью

CREATE MULTIVALUE INDEX ... ON t ( t.json_data.array.<type> )

Оптимизатор может использовать такие индексы при поиске по массиву с помощью

JSON_EXISTS ( t.json_data, '$.array?(@.<type> == ... )' )

👉 @SQLPortal

Где разместить базу данных бесплатно

Актуальные бесплатные платформы на сегодня ↓

🟢MongoDB Atlas
MongoDB — 512 МБ, автоматические бэкапы
→ mongodb.com

🟢Neon Tech
PostgreSQL — 500 МБ, 190 часов вычислений
→ neon.tech

🟢FreeDB Tech
MySQL — 25 МБ, максимум 200 подключений
→ freedb.tech

🟢Turso
SQLite — 5 ГБ, до 500 миллионов чтений
→ turso.tech

🟢Upstash
Redis — 256 МБ, 500 000 команд
→ upstash.com

🟢Xata
PostgreSQL — 15 ГБ, безлимитный трафик
→ lite.xata.io

🟢Supabase
PostgreSQL — 500 МБ, 5 ГБ трафика
→ supabase.com

🟢CockroachDB
10 ГБ хранилища, 50 млн запросов
→ cockroachlabs.com

🟢Koyeb
PostgreSQL — 1 ГБ, 5 часов выполнения
→ koyeb.com

👉 @SQLPortal

Как добиться index-only scan в Postgres?

Используйте covering indexes (покрывающие индексы).

SELECT name, email FROM web_users WHERE id = 123;

Этот запрос можно полностью покрыть индексом:

CREATE INDEX idx_users_includes
ON web_users (id)
INCLUDE (name, email);

Так Postgres сможет получить все нужные данные прямо из индекса, не обращаясь к таблице.

Хотите логировать действительно долгие запросы?

Можно настроить auto_explain так, чтобы он логировал только запросы, превышающие заданное время выполнения:

auto_explain.log_min_duration = '1000ms';

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

👉 @SQLPortal

Скрытые возможности PostgreSQL

В материале автор делится пятью возможностями, о которых редко говорят в сообществе PostgreSQL. Среди них — GRANT SELECT, DISTINCT ON, ограничения EXCLUDE и другие интересные приемы.

Читать статью: тык

👉 @SQLPortal