Postgres Professional выпускает Postgres ProGate 1.5.0 — обновление решения для миграции и репликации данных. Главными новшествами версии стали поддержка аналитической СУБД Postgres Pro AXE 2.0, перенос табличного маппинга на сторону сервера, пятикратное ускорение подготовки трансферов и существенное расширение сценариев работы с Oracle и PostgreSQL.
14 октября в логах нашего API нашлась строка «relation “message_watchdog” does not exist». Таблицы сторожа потерянных сообщений не было ни на dev, ни на проде, хотя код, который в неё пишет, жил в репозитории с апреля и на каждый вызов отвечал success: true. Рассказываю, как переименование миграции в V10b спрятало её от Flyway и почему мой мониторинг полгода докладывал, что всё спокойно.
Отказоустойчивый PostgreSQL — задача с неожиданно большим количеством инфраструктурных зависимостей. Patroni требует внешнего DCS, Stolon строит кластер вокруг keeper/sentinel/proxy и тоже опирается на внешнее хранилище, CloudNativePG ориентирован на Kubernetes, а repmgr оставляет часть задач обеспечения HA на стороне пользователя.
Мне хотелось другое: один бинарник на узел, который сам управляет PostgreSQL, сам обеспечивает консенсус и одинаково работает на обычных серверах, виртуальных машинах и в Kubernetes. Готового решения с такими свойствами я не нашёл — и написал tembo, HA-агент для PostgreSQL на Go со встроенным Raft и локальным хранилищем на bbolt.
В статье разберу, как устроены архитектура, fencing, failover и switchover, как это проверено тестами и — не менее важно — где проходят границы гарантий, которые нужно понимать до того, как доверить системе production.
Избранное можно поместить в localStorage. Пользователь нажимает кнопку, приложение сохраняет ID записи в браузере, отдельный backend для этого не нужен. Проблема появляется после добавления аккаунтов. localStorage привязан к конкретному браузеру. После входа с другого устройства сохранённого списка там нет. Простая замена localStorage на облачную таблицу тоже меняет поведение продукта, теперь для кнопки «В избранное» приходится сначала требовать авторизацию. Если гостевой режим уже работает, логичнее сохранить его и переключать источник данных после входа.
В EventMap схема выглядит так:
Для человека «е» и «ё» — повод для споров о типографике, а для базы данных и бэкенда — источник тихих коллизий, дублей и уязвимостей. Даже одна буква «ё» в Unicode может храниться двумя разными способами (U+0451 и U+0435 + U+0308), ломая len(), срезы и уникальные индексы.
Разбираемся на примерах в Python и PostgreSQL 18, чем каноническая нормализация (NFC/NFD) отличается от поисковой фильтрации (unaccent), почему стандартная нормализация не спасёт от визуальных подмен (paypal vs pаypаl по UTS #39) и как разделить контуры хранения, поиска и безопасности, чтобы не уронить прод.
Учёт документов поставщиков на стройке завода жил в двух общих книгах Excel. Кто утром первым открыл свод, тот и работал, остальным доставалось «Только чтение», а комментарий сохранялся у того, кто нажал «Сохранить» последним.
За три месяца реестр переехал в PostgreSQL, а поверх базы вырос свой BI на одной HTML-странице: дашборд, S-кривые, тепловая карта просрочек и карточки поставщиков. Без облака и без интернета, в закрытой сети завода. Рассказываю, как переезжали со сверкой до нуля расхождений, зачем серверная проверка сначала повторила старый макрос и как новый документ стал вставать на своё место в 81 % случаев вместо 47 %.
Общая сумма платежей совпадает, а суммы по дням расходятся. Причиной может быть часовой пояс подключения к PostgreSQL. На трёх платежах покажу, как paid_at::date меняет результат группировки и как явно задать часовой пояс отчёта — и для дат, и для границ периода.
Два обработчика могут успешно принять разные оплаты, но продлить подписку только один раз. На примере PostgreSQL разбираем, как теряется обновление, что меняет прибавление внутри UPDATE и какой результат нужно проверять в тесте.
Мы в Modus делаем ETL и BI, и видим чужие базы данных изнутри: на каждом внедрении, на техническом консультировании, на разборах кейсов и на каждой миграции. Навидались всякого. Но одна ошибка попадается так часто и прячется так ловко, что заслуживает отдельного разбора… и почётного звания антипаттерна. Начинаем цикл статей, посвящённых антипаттернам проектирования баз данных именно с неё.
Представьте: миграция позади. Заказы, товары и склады на месте. Число строк сошлось, проверки горят зелёным, можно закрывать задачу. Но только никто — ни аналитик, ни разработчик, ни самый хитрый SQL-запрос, — уже не скажет, с какого склада уехал конкретный товар.
Не удалено ни одного значения. А данные протеряны.
Это сбой миграции? Ошибка в запросе? Нет!
Это ошибка проектирования, которая очень похожа на безобидную нормализацию. Давайте разберём, откуда она берётся, почему стандартные проверки её не видят и почему исправить её задним числом уже нельзя. Не «дорого и сложно», а вообще невозможно математически.
А в конце — задачка для тех, кто (как и мы когда-то) уверен, что опыт и знания надёжно ограждают его от таких новичковых ошибок.
Утром в отчёте 25% продлений за вчера, но у части подписчиков ещё есть время на оплату. На примере PostgreSQL покажу, как сравнивать дни с полным 48-часовым окном, засчитывать предоплату и обрабатывать платёж ровно на границе срока.
12 ноября компания Postgres Professional проведёт 12 ноября бесплатный вебинар, посвящённый Postgres Pro Enterprise Manager (PPEM) — графической платформе для централизованного мониторинга, диагностики и администрирования баз данных. Эксперты покажут, как управлять парком экземпляров СУБД из одного интерфейса, находить причины проблем с производительностью и контролировать отказоустойчивые кластеры.
На консультацию осталось одно место, а кнопку «Оплатить» нажали двое. Покажу, как зарезервировать слот до оплаты в Telegram Stars, проверить блокировку в двух сессиях PostgreSQL и обработать платёж, который пришёл после истечения резерва.
Когда сервис живёт на сотне PostgreSQL-шардов, даже вопрос «где лежит запись с таким ID?» легко превращается в обход десятков подключений. Сущности распределены консистентным хешированием, а редкие операции на нагруженных таблицах требуют отдельно следить за lock_timeout, statement_timeout и пулом соединений.
Я бэкенд-разработчик высоконагруженных сервисов, в прошлом DBA. Штатные миграции у нас раскатываются автоматически. Но когда изменение требует отдельного контроля на нагруженной таблице, не хочется полагаться только на то, что разработчик проверил скрипт и ничего не забыл.
Так за пару дней совместной работы с ИИ появился Terox — CLI, который ищет данные по набору шардов, переключается на найденный и раскатывает сложный SQL через dry-run, canary и батчи. Рассказываю, как рабочая боль превратилась в open-source инструмент и почему при работе с production-базами вайбкодинг быстро превращается в обычную инженерную работу.
Главная жалоба на чат-ботов всегда одна: «он меня не помнит». Своей памяти у LLM нет, и всё, что она якобы помнит, кладём в контекст мы сами.
Рассказываю, как устроена память ассистента в проде на 16 тысячах раундов: файлы, PostgreSQL с pgvector, судья на дешёвой модели, выжимки, политика доступа между агентами. И что из задуманного так и осталось лежать в библиотеке.
В версии 1.10 добавили несколько крупных возможностей для мониторинга PostgreSQL. Теперь Dasha умеет автоматически находить кластеры Patroni через etcd и Consul, показывать активность и ожидания сессий в реальном времени, оценивать, когда отставший слот репликации может выйти за допустимый лимит WAL.
Кроме того, доработали Health Score, добавили мониторинг операций COPY и расширили MCP-коннектор.
Всем привет!) Про топовые модели пишут много. Мне стало интересно другое: что будет, если отдать реальную задачу быстрой модели без громкого имени, а рассуждающую модель подключать только тогда, когда первая упирается не в синтаксис, а в поведение системы? Стек такой: VS Code (Cline), Particle-1 как кодер ( "руки"), GPT-6 Luna Pro как "мозг", Tilda (отдельная страница с формой), n8n , PostgreSQL 16, Docker.
Сам замысел что не в чате "напиши мне функцию...", а в роли кодера в VS Code через Cline: модель пишет SQL и JavaScript для нод n8n, получает текст ошибки, предлагает следующий патч и т.д. до рабочего результата.
Задачу взял из рабочего проекта: поиск по каталогу изделий. На вид вроде бы выглядит как "ввёл теги = получил карточки". Под поверхностью оказались массивы в PostgreSQL, особенности передачи данных между нодами n8n, перекошенный источник и SQL-инъекция, которую на финальном ревью нашёл уже я, а не LLM.
Сразу оговорюсь: это разбор одного рабочего кейса, а не A/B-бенчмарк. Модели выполняли разные роли и не решали одинаковый набор задач в контролируемых условиях. Поэтому я не пытаюсь доказать, что одна из них объективно "лучше". Мне было важно другое - как такое разделение ролей ощущается в реальной разработке с данными LLM и где всё равно нужен человек.
Привет, Хабр! Я Михей, пишу на Go, собираю свои системы и рассказываю, где они ломались, пока не заработали. Сегодня про базу, которую слишком рано записывают в виноватые.
Когда сервис начинает тормозить, у кого-то первая мысль одна: база не вывозит, пора шардировать. Знакомо? А между «тормозит» и «шардируем» на деле лежит несколько шагов, которые стоят заметно дешевле. Про них почему-то вспоминают в последнюю очередь.
Теорию пересказывать не стал. Я прогнал всё на стенде и записал, сколько каждый шаг реально даёт, чтобы ты не гадал. Сначала разберём, что делать заранее, чтобы до беды не дошло. Потом, что делать, если база уже тормозит. Все примеры на PostgreSQL 16, все цифры мои, условия замера описаны рядом. Там, где я что-то не мерил, я так и пишу.
Четверг, 14:15. Миграция с флагом фичи на таблице с 30M строк применилась в стейджинге за 12 миллисекунд. Но через 18 секунд после деплоя в прод Nginx взорвался 504 Gateway Timeout, а PgBouncer исчерпал весь пул соединений. Разбираем анатомию катастрофы: почему Postgres берет ACCESS EXCLUSIVE, как возникает Head-of-Line Blocking и как писать zero-downtime миграции без падения сервисов.
Я делаю планировщик задач Clarify. Один, в свободное время, для себя. Разработчик из меня любительский, так что профессионалы в комментариях наверняка найдут, что мне сказать. Десктоп на Flutter под Windows, на телефоне та же сборка как PWA. База и авторизация в Supabase, а для того, что нельзя делать на клиенте, был маленький FastAPI на бесплатном Render.
Про блокировки хостингов на Хабре писали много. Я хочу рассказать не про сам переезд, он как раз скучный. Хочу про то, сколько всего продолжало стучаться на старый адрес после того, как я решил, что всё перенёс. И как я этого не замечал.
Некоторое время назад к нам обратился клиент, у которого после миграции с MS SQL на PostgreSQL закрытие месяца в 1С:ERP стало вместо 12 минут проходить за 8 часов. В статье рассказываем, как мы выявили причину в оценке Hash Join, которую планировщик завышал в миллионы раз, и как исправили её так, что проблемный запрос теперь выполняется за 18 секунд вместо целого часа.
