Разобрали, почему PostgreSQL рекомендуют запускать с режимом Strict Memory Overcommit в Linux.

В статье объясняется:

Что такое memory overcommit и почему стандартное поведение Linux может быть опасно для PostgreSQL.

Как OOM Killer способен завершить процесс Postgres при нехватке памяти, оставив сервер без возможности принимать новые подключения.

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

Какие параметры ядра (vm.overcommit_memory, vm.overcommit_ratio) влияют на работу PostgreSQL и как подобрать их для стабильной работы сервера.

Полезный материал для DBA, DevOps и всех, кто администрирует PostgreSQL в Linux и хочет лучше понимать причины OOM-ошибок и настройки памяти.

https://clickhouse.com/blog/strict-memory-overcommit-for-postgres

👉 @SQLPortal

Большой шаг вперёд для PostgreSQL

Долгое время полнотекстовый поиск считался одной из слабых сторон Postgres. Если требовался качественный поиск с ранжированием по релевантности, обычно приходилось разворачивать Elasticsearch, подключать Algolia или использовать другие внешние сервисы, постоянно синхронизируя данные.

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

Из-за этого многие команды были вынуждены:

• Поднимать отдельный кластер Elasticsearch только ради поиска.
• Поддерживать пайплайны синхронизации данных между системами.
• Платить за управляемые поисковые сервисы.
• Мириться с не самым качественным ранжированием результатов.

Теперь появилась альтернатива — pg_textsearch, новое open-source расширение для PostgreSQL от TigerData.

Что оно предлагает:

• Поддержку алгоритма BM25 — того самого, который используется в Elasticsearch, Lucene и большинстве современных поисковых систем.
• Простой SQL-синтаксис для поиска:

ORDER BY content <@> 'search terms'

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

Расширение распространяется с открытым исходным кодом по лицензии PostgreSQL и позволяет реализовать современный поиск прямо внутри Postgres, без необходимости использовать отдельную поисковую инфраструктуру.

https://github.com/timescale/pg_textsearch

👉 @SQLPortal

Нашли удобный инструмент для миграций баз данных на Go — goose.

Что умеет:

• Управлять миграциями схемы базы данных через SQL-файлы или Go-функции.
• Работать с PostgreSQL, MySQL, MariaDB, SQLite, ClickHouse, SQL Server и другими популярными СУБД.
• Поддерживает откат миграций, применение до нужной версии, проверку статуса, сидирование данных и миграции, встроенные прямо в Go-приложение.

Полезный инструмент для Go-разработчиков, который помогает поддерживать структуру базы данных в актуальном состоянии, автоматизировать развёртывание и интегрировать миграции в CI/CD.

https://github.com/pressly/goose

👉 @SQLPortal

Нашли отличный материал о том, какие проблемы может создавать MVCC (Multi-Version Concurrency Control) в PostgreSQL и почему этот механизм не так прост, как кажется.

В статье разбирается, как MVCC позволяет чтению и записи выполняться без взаимных блокировок, но одновременно приводит к появлению «мёртвых» версий строк (dead tuples), росту размера таблиц, дополнительной нагрузке на VACUUM и другим скрытым издержкам. Автор объясняет, почему каждое UPDATE фактически создаёт новую версию строки и как это влияет на производительность базы данных.

Отличный материал для тех, кто хочет глубже понять внутреннее устройство PostgreSQL, разобраться в работе MVCC, механизмах видимости строк, VACUUM, HOT Updates и причинах деградации производительности при больших объёмах обновлений.

https://boringsql.com/posts/mvcc-bad-bad/

👉 @SQLPortal

Полезный совет для PostgreSQL

Знаете ли вы, что автоматизировать задачи в PostgreSQL можно с помощью расширения pg_cron?

Оно позволяет создавать задания по расписанию прямо внутри базы данных — без использования внешнего планировщика.

С помощью pg_cron можно автоматизировать, например:

• запуск VACUUM;
• обновление материализованных представлений (Materialized Views);
• выполнение регулярных SQL-запросов;
• другие задачи обслуживания базы данных.

Чтобы посмотреть список всех запланированных заданий, выполните:

SELECT * FROM cron.job;


pg_cron — удобный инструмент для автоматизации рутинных операций и поддержки PostgreSQL в рабочем состоянии без внешних средств планирования.

👉 @SQLPortal

Оптимизируйте работу с SQL

Улучшаем процесс разработки, добавив две мощные возможности: оператор Flow (->>) и UNION BY NAME.

Оператор Flow позволяет объединять SQL-запросы в цепочки по аналогии с Unix-конвейерами, где результат одного шага автоматически становится входными данными для следующего. Это делает код чище, избавляет от необходимости использовать временные таблицы или RESULT_SCAN() и позволяет строить более гибкие аналитические пайплайны.

UNION BY NAME выводит объединение данных на новый уровень. Вместо сопоставления столбцов по их порядку он автоматически объединяет их по именам. Это значительно упрощает работу с изменяющимися схемами данных, а отсутствующие столбцы автоматически заполняются значением NULL. Больше не нужно вручную переименовывать столбцы перед объединением.

Используя эти возможности вместе, вы сможете создавать более надежные, понятные и удобные в сопровождении SQL-пайплайны.

Подробности и примеры использования по ссылке.

👉 @SQLPortal

Не направляйте каждый аналитический запрос или задачу поиска данных для ИИ-агентов напрямую в рабочую базу данных.

Spice — это open-source рантайм на языке Rust для разработчиков, которым нужны SQL-запросы, поиск и LLM-инференс рядом с существующими источниками данных.

Он помогает создавать приложения и ИИ-агентов, работающих с реальными данными, объединяя различные источники и предоставляя SQL, гибридный поиск и OpenAI-совместимые API из единого переносимого рантайма.

Основные возможности:

• Нативный CDC (Change Data Capture) — реплицирует изменения из PostgreSQL, MySQL и MongoDB, создавая готовые для аналитики реплики.
• Федеративные запросы — подключается более чем к 30 источникам данных и поддерживает query push-down для выполнения части запроса непосредственно в источнике данных.
• Гибридный поиск — объединяет векторный и полнотекстовый поиск с поддержкой RRF (Reciprocal Rank Fusion) и SQL-функций для повторного ранжирования результатов.
• Интерфейсы для ИИ — включает OpenAI-совместимые API, MCP-сервер и шлюз, а также поддержку Text-to-SQL.
• Гибкое развёртывание — может работать как один исполняемый файл, контейнер, sidecar или распределённый кластер.

https://github.com/spiceai/spiceai

Проект полностью open-source и распространяется по лицензии Apache 2.0.

👉 @SQLPortal

Нашли лёгкую альтернативу phpMyAdmin для работы с SQL-базами

Adminer — это веб-клиент, состоящий всего из одного PHP-файла.

Что умеет:

• Поддерживает PostgreSQL, MySQL, MariaDB, SQLite, Oracle, MS SQL и другие СУБД.
• Позволяет выполнять SQL-запросы, управлять таблицами, индексами, пользователями, а также импортировать и экспортировать данные.
• Поддерживает плагины, расширяющие возможности и добавляющие поддержку других источников данных.

Удобный инструмент, когда нужен быстрый веб-доступ к базе данных без установки тяжёлых клиентов.

https://github.com/vrana/adminer

👉 @SQLPortal

Универсальный open source-клиент для работы с базами данных

Нашли удобный инструмент для работы с SQL и NoSQL базами данных.

WhoDB — это open source-клиент с современным веб-интерфейсом, который поддерживает PostgreSQL, MySQL, SQLite, MariaDB, ClickHouse, MongoDB, Redis, Elasticsearch и многие другие СУБД.

Что умеет:

• Подключаться к популярным SQL и NoSQL базам данных
• Выполнять SQL-запросы с подсветкой синтаксиса и автодополнением
• Просматривать и редактировать данные в удобной табличной форме
• Визуализировать структуру базы и связи между таблицами (ERD)
• Импортировать и экспортировать данные
• Работать с ИИ: задавать вопросы к данным на естественном языке через OpenAI, Anthropic, Ollama, Gemini и другие совместимые модели
• Запускаться через Docker, как десктопное приложение, CLI или MCP-сервер для интеграции с ИИ-ассистентами

https://github.com/clidey/whodb

👉 @SQLPortal

Apache Cassandra — одна из самых популярных распределённых NoSQL-баз данных, разработанная для хранения огромных объёмов информации с высокой отказоустойчивостью и линейной масштабируемостью.

Проект входит в экосистему Apache Software Foundation и используется в системах, где критически важны доступность и производительность.

Что умеет:

• Линейно масштабируется — новые узлы можно добавлять в кластер без остановки сервиса, увеличивая производительность практически пропорционально количеству серверов.
• Использует masterless-архитектуру — все узлы равноправны, поэтому отсутствует единая точка отказа. Поддерживается репликация между дата-центрами и регионами.
• Работает через CQL (Cassandra Query Language) — язык запросов, синтаксис которого во многом напоминает SQL, что упрощает освоение для разработчиков.
• Поддерживает высокую скорость записи, автоматическое распределение данных, резервное копирование, индексацию, пользовательские типы данных, агрегатные функции и lightweight-транзакции.

Apache Cassandra особенно хорошо подходит для высоконагруженных систем: IoT, банковских сервисов, телеком-платформ, систем мониторинга, рекомендательных сервисов и других приложений, где требуется обрабатывать большие объёмы данных без простоев.

https://github.com/apache/cassandra

👉 @SQLPortal

SQL или NoSQL — редко бывают главной проблемой.

Гораздо чаще настоящая причина низкой производительности — это:

• плохо спроектированная схема базы данных;
• отсутствие необходимых индексов;
• неудачная модель хранения и организации данных.

Именно эти факторы обычно оказывают гораздо большее влияние на производительность и масштабируемость системы, чем выбор между SQL и NoSQL.

👉 @SQLPortal

Нашли подробный разбор самых распространённых ошибок при эксплуатации PostgreSQL

Автор на основе реальных аудитов СУБД собрал 10 проблем, которые чаще всего встречаются в production-системах, и объяснил, как их обнаружить и исправить.

Что разбирается в статье:

• Резервное копирование PostgreSQL: почему наличие бэкапов ещё не гарантирует возможность восстановления данных.
• Типичные ошибки безопасности: использование суперпользователя приложением, слишком широкие правила доступа в pg_hba.conf и отсутствие TLS.
• Настройка логирования, контрольных сумм, мониторинга, поиск долгих транзакций, борьба с bloat и правильная работа autovacuum.
• Оптимизация конфигурации PostgreSQL под реальную нагрузку, архитектурные ошибки, а также проверка соответствия требованиям RTO/RPO и отказоустойчивости.

Материал будет полезен DBA, DevOps, системным администраторам и всем, кто отвечает за эксплуатацию PostgreSQL в production. В статье не только разбираются причины возникновения проблем, но и приводятся практические рекомендации, SQL-запросы и примеры их решения.

https://habr.com/ru/companies/k2tech/articles/1064474/

👉 @SQLPortal

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

sqlit — это быстрый TUI-клиент с поддержкой большого количества СУБД, автоматическим обнаружением Docker-контейнеров, историей запросов и умным автодополнением команд. И всё это — без тяжёлых и требовательных к памяти приложений.

Если вы часто работаете с SQL из терминала, sqlit определённо стоит попробовать.

https://github.com/Maxteabag/sqlit

👉 @SQLPortal

Нашли интересный способ упростить работу с JOIN в PostgreSQL

Автор предлагает автоматически генерировать функции на основе foreign key, чтобы выполнять соединения без ручного написания JOIN ... ON. Такой подход делает SQL-запросы короче, снижает вероятность ошибок и приближает работу с базой данных к навигации по связям, как в ORM.

Что разбирается в статье:

• Почему классический синтаксис JOIN заставляет каждый раз повторять уже известные базе связи и какие проблемы это создаёт.
• История попыток добавить в SQL соединения по внешним ключам (KEY JOIN) и почему эта идея до сих пор не стала частью стандарта.
• Проект pg_relation_sql, который автоматически создаёт функции навигации по внешним ключам и позволяет писать запросы в стиле client(document) вместо длинных JOIN ... ON.
• Сравнение производительности с обычными JOIN, ограничения подхода и примеры использования в реальных запросах.

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

https://habr.com/ru/articles/1065684/

👉 @SQLPortal