Привет, Хабр! Меня зовут Анастасия Нечепоренко, я QA Lead и преподаватель курса "JavaScript QA Engineer" в Отус. В этой статье кратко разбираю самые живучие мифы о SQL и NoSQL: от «схемы нет — значит свобода» до «реляционные БД не масштабируются». Поговорим, где каждый класс СУБД уместен, чем приходится платить за горизонталь и консистентность и почему в реальных проектах гибридный подход чаще выигрывает.
Команда Go for Devs подготовила перевод обзора PostgreSQL 18. Новый релиз не ограничился громкой подсистемой асинхронного ввода-вывода — он принёс ряд функций, заметных именно в повседневной разработке. Нативная поддержка UUID v7, виртуальные генерируемые столбцы, расширенные возможности RETURNING и новые средства диагностики делают жизнь разработчиков проще и продуктивнее.
На прошлой неделе мне предоставилась возможность прочитать научную статью 1986 года о создании Postgres как платформы и о исходных целях её проектирования. Меня поразила степень предусмотрительности её авторов и то, как цели проекта заложили фундамент создания системы управления базами данных, постепенно завоёвывающей мир.
Создатели PostgreSQL справились со своей задачей идеально. Они создали гибкий каркас для широкого спектра сценариев использования в бизнесе системы, которая спустя тридцать лет стала самой популярной СУБД.
В статье перечислены следующие шесть целей проекта:
1. улучшенная поддержка сложных объектов, расширяющих сценарии использования в бизнесе и разработке
2. обеспечение возможности расширения типов данных, операторов и способов доступа для пользователей
3. предоставление средств для активных баз данных (например, уведомлений и триггеров)
4. упрощение процесса восстановления после сбоев
5. использование преимуществ нового оборудования
6. применение реляционной модели Кодда
Давайте рассмотрим их с точки зрения современных возможностей Postgres.
В мире баз данных, где каждая миллисекунда на счету, а объемы информации растут как на дрожжах, выход PostgreSQL 18 стал настоящим подарком для разработчиков и администраторов. Это не просто косметический апгрейд, а глубокая перестройка подкапотных механизмов, от облачных хранилищ до высоконагруженных OLAP-систем. Давайте разберемся, что там в этом релизе появилось и/или изменилось.
Команда Python for Devs подготовила перевод статьи о том, как найти самый быстрый способ загрузки данных в PostgreSQL с помощью Python. Автор пошагово сравнил разные методы — от построчных вставок до COPY с потоковой генерацией CSV — и показал, как ускорить процесс более чем в 250 раз при нулевом потреблении памяти.
Можно ли перейти с Oracle или MS SQL на СУБД из Реестра российского ПО без переписывания всей хранимой логики?
Один из возможных подходов к решению этой задачи.
Любите ли вы SQL так же, как и я? Недавно, собирая огромный SQL‑запрос, я понял, что надо что‑то менять.
Логическим блоком в SQL является подзапрос или CTE и вроде бы можно разбивать запрос по блокам и работать с ними отдельно, как строится по кирпичикам любое приложение.
Однако когда весь текст запроса идет сплошняком на многие экраны, сложно и разрабатывать, и через длительное время понимать алгоритм запроса.
А что, если не надо писать SQL? В SAP мы не писали запросы, мы создавали Calculation View, и работать с ними было на порядок быстрее и приятнее.
Перефразируя диалог из Матрицы:
— Когда я стану избранным, я смогу писать длинный SQL?
— Тебе не надо будет писать SQL.
Работаете с PostgreSQL и хотите попробовать MongoDB? Я спроецировал опыт работы с реляционными БД на NoSQL и собрал два чек-листа: проверенные практики для PostgreSQL и их аналоги для MongoDB.
Без воды, только ключевые пункты чтобы быстро стартовать и не наступать на типичные грабли.
Нормализация vs Денормализация: Mongo, Postgres и реальная жизнь. Почему у нас вырастает 160 таблиц там, где мог быть один jsonb? И как понять, когда денормализация — это костыль, а когда осознанный выбор?
Если при слове «нормализация» у тебя начинается зевота, а менеджер с порога предлагает «спроектировать базу» — этот текст для тебя.
В конце августа вышел релиз распределённой СУБД Apache Cloudberry 2.0.0 — опенсорс‑проекта, который в режиме инкубации находится в Apache Soft Foundation (ASF). В новой версии состоялся переход на кодовую базу PostgreSQL 14, а также было добавлено множество улучшений.
При этом на Хабре до сих пор незаслуженно мало статей, посвящённых этой СУБД. Мы решили исправить это совместно с Максом Янгом, техническим лидером и участником PPMC Apache Cloudberry (Incubating). Эти статьи созданы по материалам совместного митапа Yandex Cloud Data Platform — про Greenplum® и не только. В этот раз пройдёмся по базовым особенностям и функциям этой СУБД, а в следующий — доберёмся до advanced‑возможностей.
Всю свою карьеру инженеры строят системы, которые бережно хранят данные и защищают их от искажений. А что если мы скажем, что иногда правильнее всё делать наоборот: намеренно портить данные, генерировать их из воздуха и создавать неотличимые от настоящих подделки? Системный аналитик Postgres Professional Максим Грамин расскажет, почему создание фейковых данных — это критически важный навык для тестирования, безопасности и разработки, и как научиться делать это правильно, не превращая базу в свалку из «Иванов Ивановых».
Сегодня я хочу рассказать вам об одном из вариантов доставки событий для распределённого приложения на Java.
Это доставка событий через БД, в которой хранится состояние распределённого приложения.
PostgreSQL 18 вот-вот выйдет, и это не просто минорное обновление, а настоящий прорыв для разработчиков и администраторов БД. В новом переводе от команды Spring АйО рассмотрим ключевые новинки — асинхронный I/O для ускорения чтения, поддержка UUID версии 7 с улучшенной сортировкой, skip scans в B-tree индексах, виртуальные вычисляемые столбцы и даже OAUTH 2.0 для аутентификации. Всё это делает Postgres ещё более быстрым, гибким и современным.
Self-modifying SQL — это техника, при которой SQL-запросы не просто выполняют фиксированную операцию, а генерируют, изменяют и выполняют другие SQL-запросы во время работы приложения. Эта концепция может показаться экзотической и даже спорной, но в определённых сценариях она позволяет создать гибкие, адаптивные решения для динамического управления базой данных.
Эта статья предназначена для разработчиков всех уровней: от начинающих, которые хотят понять основы динамического SQL, до продвинутых специалистов, интересующихся нетривиальными приёмами и автоматизацией управления данными.
Про протокол MCP (Model Context Protocol) сейчас говорят всё чаще. Этот протокол позволяет нейросетям общаться с внешним миром. С его помощью к LLM можно подключать любые источники данных или системы управления, и всё это через один универсальный стандарт. MCP часто сравнивают с USB — устройство одно, протокол один, а число сценариев применения практически бесконечно.
В статье расскажу про практический сценарий «как связать LLM и базу данных». Это может сделать любой на своём компьютере.
Протокол MCP придумали ребята из Anthropic. Далее будем использовать нейросети Claudе Sonnet и Claude Opus — это LLM от Anthropic.
Зачем это нужно? Такая связка позволит промтами вытаскивать инсайты из данных, создавать отчёты в PDF и строить интерактивные отчёты в HTML. Это работает на моём компьютере последние два месяца и результаты очень обнадёживающие.
Чтобы было интереснее, в качестве данных возьмём все вакансии Habr Career c описаниями.
В одной из московских школ мы сделали Telegram-бота, который автоматизировал «операционку»: согласия на мероприятия, запись на кружки, заявки в хозчасть/ИТ, массовые оповещения, анонимный канал психолога и контур директора с согласованиями и дашбордами. Я старался максимально упростить сложную и разрозненную модель управления.
Проект реально сработал, но его пришлось закрыть: с 2025/26 учебного года все школьные коммуникации перевели в национальный мессенджер «Макс» (MAX), а Telegram оказался «под запретом».
Знакомо чувство, когда интеграционные тесты с PostgreSQL в Go работают дольше, чем хотелось бы? Каждый тест создает базу заново, применяет миграции, и большая часть времени уходит не на проверку логики, а на подготовку окружения. В этой статье я расскажу о своем open-source решении на Go, которое использует встроенные механизмы шаблонов PostgreSQL, чтобы ускорить этот процесс в полтора раза, уменьшить потребление памяти и сделать ваши тесты по-настоящему параллельными.
В статье рассматривается логирование соединений с базами данных кластера PostgreSQL. Системы мониторинга создают сессии для сбора метрик и проверки доступности экземпляра. Это создаёт большое число записей в диагностическом журнале кластера, затрудняя его анализ. Администраторы ищут возможность отключения логирования для сессий мониторинга. Такая возможность есть только у параметра log_disconnections. Приводится пример, как с его помощью отключить логирование при создании сессии. Также рассматриваются особенности использования расширений pgaudit и pgaudittofile, которые позволяют выводить логирование соединений в отдельный файл аудита.
25 сентября в Москве мы снова собираем участников Java-сообщества вместе. В программе: хардкорные доклады, дискуссия о будущем Spring в России и много живого общения.
Регистрируйтесь на митап по ссылке.
А пока присоединяйтесь к нашему ТГ-каналу и чату Java Rock Stars Meetup, чтобы быть в курсе новостей митапа.
Регулярные выражения (или regex) — это особые текстовые строки, используемые для описания поискового шаблона. В PostgreSQL regex становится незаменимым инструментом, особенно при работе с большими объёмами неструктурированных строковых данных.
Возможно, у кого‑то есть вопрос: «А для чего нам регулярные выражения в БД?» И мы вам ответим:
Регулярные выражения (regex) позволяют описать сложные текстовые шаблоны компактно и гибко.
