Всё, уже официальная версия.
замечания к выпуску (release notes),
Как всегда, все основные особенности обсудили ещё задолго до официальной, начав с первых бет (мы, например, говорили о некоторых статьях на эту тему ещё в номере Postgresso 3-4 за 2025, когда вышла самая 1-я бета).
Вот что подчёркивают в официальном релизе:
Я прочитал статью, и меня поразило, сколько сомнительных решений можно использовать для одной простой задачи.
В этой статье я расскажу, как правильно создать сервис для конкурентных обновлений остатков данных в базе данных. Буду использовать .NET, C#, Entity Framework и PostgreSql.
В мире, где абстракции правят бал, а скорость важнее эффективности, говорить о C — значит идти против течения. Для многих это «устаревший» язык с ручным управлением памятью и «опасными» указателями. Но что, если именно эти его особенности — не минусы, а ключи к системному программированию, где нет права на ошибку? Программистом Postgres Professional с 22-летним стажем Максим Орлов убеждён, что C — не про мгновенный дофамин и быстрые прототипы, а про суть, контроль и философское понимание того, как действительно работает железо. Погрузитесь в историю любви к C, которая началась с раздражения на Pascal, и узнайте, почему этот «бастион спокойствия» актуален и сегодня.
Статья описывает методику миграции приложения, содержащего множество SQL запросов из базы данных Oracle в Postgres. Будет интересна всем, кто собирается мигрировать или уже мигрировал приложение из Oracle в Postgres.
Традиционные подходы к генерации SQL-запросов часто полагаются на инструктированные языковые модели, но они могут быть неэффективными и неточными. Мы рассмотрим новый подход, основанный на использовании Reinforcement Learning для дообучения моделей, который может улучшить точность и эффективность генерации SQL.
Привет, Хабр!
Предлагаю сегодня разобраться, как семантический поиск появился в Laravel и PostgreSQL.
У нас 1С развёрнут на Linux и PostgreSQL. Всё началось с запроса клиента на развёртывание 1С в Linux-среде. Мы создали первый кластер, а затем перевели всю облачную 1С на open source.
В этой статье расскажем о нашем пути, сложностях и результатах. Больше подробностей об особенностях работы облачной 1С вы узнаете на вебинаре — запись эфира открыта по ссылке.
Временные, или промежуточные данные — это данные, которые необходимы для обработки в рамках одной транзакции, сессии или в течение ограниченного периода, и удаляются после его завершения. Использование временных данных применяется в случаях, когда обработка всей информации за один запрос невозможна или нецелесообразна. Поэтому приложение может выполнять обработку по частям, используя несколько запросов.
В статье будут рассмотрены основные методы хранения временных данных в PostgreSQL: обычные таблицы, нежурналируемые таблицы, материализованные преставления, временные таблицы и память серверного процесса с использованием расширения pg_variables.
Это был обычный понедельник. Я пил кофе, проверял почту, и вдруг — волна уведомлений в Slack. «Сайт не грузится!», «Отчеты зависли!», «Что происходит?».
Наш проект, который успешно работал с несколькими сотнями тысяч записей, перешагнул психологически важный рубеж — 10 миллионов строк в таблице заказов. И PostgreSQL, который раньше летал, внезапно начал ползти как улитка.
Сегодня поговорим про восстановление повреждённых данных в СУБД семейства постгрес. Речь именно о повреждённых данных, когда сам постгрес их прочитать уже не может. Задача восстановления таких данных нетривиальная. Тут нет и быть не может универсальных рецептов, иначе они давным давно уже были бы реализованы в виде утилит. Статья написана по мотивам моего выступления на конференции PGConf.Russia в 2023 году. Только сейчас дошли руки её написать, хотя в планах подготовка статьи была изначально. Могу сказать, что в плане восстановления повреждённых данных за эти годы ничего не поменялось, вся информация актуальна.
25 сентября вышел PostgreSQL 18 — релиз, где маркетинговое «в 3 раза быстрее» подкреплено конкретной работой над вводом‑выводом, планировщиком и инструментами миграции. Ниже — без лозунгов и фанфар: разберём, что и как вам поможет в проде.
Добрый день, коллеги!
Сегодня я хочу поделиться некоторыми проблемами (и решениями) при создании большого количества индексов и ограничений целостности (констрейнтов) одновременно.
Но для начала хочу порассуждать о том, почему вообще возникли такие вопросы.
При развёртывании новой крупной базы данных с «нуля» (например путём миграции), возникает необходимость построить также большое количество индексов в весьма ограниченное тех. окно. Как известно, процесс построения индекса это не только ценный мех IO, но и довольно большое количество CPU при достаточно производительной дисковой подсистеме. Чем больше ядер вы сможете задействовать — тем быстрее пойдёт процесс (в общем случае утверждение, конечно, спорное, но в моём случае обоснованное и проверенное).
На пути «параллелизации» всего и вся возникают разнообразные проблемы, про 3 такие проблемы я и хочу рассказать сегодня.
Привет, Хабр! Меня зовут Анастасия Нечепоренко, я 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.
Без воды, только ключевые пункты чтобы быстро стартовать и не наступать на типичные грабли.
