PostgreSQL *

Разбираем переезд интернет-магазина с OpenCart 2 на Next.js и PostgreSQL. Магазин оптовый, электронные компоненты, сайту двадцать лет, в каталоге 4 751 товар. Если у вас OpenCart и вы думаете уезжать, то будет полезно почитать, что может всплыть в самый неожиданный момент.

Магазин запущен в боевом режиме, поэтому всё ниже про то, что уже перенесено и работает. Про трафик после переключения домена говорить рано, замера ещё нет. Обмен с учётной системой - отдельная большая тема, и здесь его нет.

Всем привет! Я Дмитрий Пономарев, разработчик ESB ИТ-интегратора «Белый код»! Сначала всё выглядело довольно просто: забираем данные по REST API, обрабатываем и сохраняем в PostgreSQL. Проблемы начались, когда объём таблицы вырос до десятков миллионов строк, а несколько миллионов записей пришлось регулярно проверять заново.

В одном из проектов мы столкнулись именно с такой задачей. DATAREON Platform должен был получать данные через REST API, сохранять их в PostgreSQL, хранить историю состояний и каждый день повторно проверять актуальные записи. На небольших объёмах схема работала нормально, но после роста данных стало ясно: последовательная обработка и вычисление актуальной версии записи «на лету» больше не укладываются в рабочее окно.

В этой статье разберём, как мы перестроили интеграцию: вынесли актуальность записи в отдельный признак, добавили специализированные индексы PostgreSQL, распараллелили обработку через воркеры DATAREON и предусмотрели безопасное восстановление после сбоев. В итоге производительность промышленной актуализации удалось довести примерно до 1,1–1,2 млн объектов в час.

С redb команда пишет только бизнес-логику: что экосистема заменяет, во что обходится, какие риски снимает и что важно знать до старта.

12 сентября вышла redb 4.0.0. Четыре продукта экосистемы (хранилище, интеграционный движок, рантайм и сервер идентификации) получили общий мажорный номер: 76 пакетов, внутренний аудит безопасности и сборку на .NET 10, который Microsoft поддерживает до ноября 2028 года. Для инженеров изменения разобраны в отдельной статье. Этот текст для тех, кто решает, на чём строить бэкенд: что экосистема заменяет, во что обходится, какие риски снимает и что важно знать до старта.

Коротко, из чего она состоит:

SELECT FASTTRUNCATE нет в документации PostgreSQL, но на боевой базе эта команда занимала 12.9% времени всех запросов. Разбираем, как платформа 1С на самом деле работает с временными таблицами, почему УНИЧТОЖИТЬ в запросе ничего не уничтожает и что изменилось в 8.3.25.

Не открою секрет, если скажу, что обычный поиск по ключевым словам уже не особо помогает. Чтобы нейросети могли отвечать точно, опираясь на ваши корпоративные базы знаний, им нужно «понимать» смысл текста. А это уже сложнее, чем просто искать точные совпадения букв. 

В этой статье мы разберем, как устроены векторные базы данных, почему без них не работает современный RAG, чем они отличаются от привычных реляционных БД и как выбрать подходящий инструмент для своего проекта.

Привет, Хабр. Я хочу рассказать историю, которую вы уже, наверняка, где-то слышали. Только с другой стороны.

Пару месяцев назад я сидела на созвоне с техдиром стартапа, который делал RAG-систему для юридических документов. Он сказал, что они уходят с Postgres на Pinecone, потому что Postgres для векторов не тянет, это же очевидно. Я спросила, сколько у них векторов. Оказалось, тысяч двести, может, триста. Я уточнила, пробовали ли они вообще pgvector. Выяснилось, что нет, решение приняли по общему ощущению, что Postgres для этого не годится. Ощущение было не на пустом месте, два года назад так и было. Я не стала спорить. Просто открыла документацию pgvector и скинула ссылку. Через неделю он написал, что оно работает. Даже быстрее, чем они думали. Ещё через месяц они запустили прод. На одном Postgres. Без Pinecone. Без отдельной векторной базы. Без трёх месяцев инфраструктурной работы, которую они уже успели запланировать.

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

В прошлой статье про PostgreSQL я разбирал три инцидента на стороне базы — блокировки, bloat и ночные пересчёты. В комментариях несколько человек написали примерно одно и то же: «база базой, а покажи, что творилось на стороне приложения — пул-то небось тоже горел».

Горел. Ещё как.

Это продолжение того же разбора, но на слой выше — про HikariCP, дефолтный пул соединений в Spring Boot. Тот самый, который «просто работает», пока не перестаёт. Проекты те же, что и в статье про миграцию и в статье про PostgreSQL: банковская система после переезда с Oracle (терабайт, 70+ таблиц, 500–3000 RPS на чтение и 50–300 на запись в пике) и enterprise-платформа на Java/Spring, где PostgreSQL жил под Hibernate. Разные команды, разные нагрузки, но сюжет один: сервис встаёт, в логах Connection is not available, и первое, что делает любой человек, — лезет крутить maximumPoolSize. И почти всегда делает хуже.

Это не туториал «как настроить HikariCP за 10 строк». Таких на Хабре хватает, и половина из них сводится к «поставьте пул побольше». Здесь — список мест, где у нас всё ломалось, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой».

Если вы сейчас живёте на HikariCP — читайте как чеклист. Если уже прошли через это — сверьте, сколько совпало.

Дисклеймер: проекты под NDA, названия, точные объёмы и часть деталей изменены. Порядок величин, конфиги и сами инциденты — настоящие.

Меня зовут Кирилл Манин, я почти шесть лет работаю в команде SQL DBA и занимаюсь развитием платформы баз данных Авито.

Почти всё это время к нам регулярно обращались разработчики микросервисов: «Можно нам читать с реплик?» и «Как подключиться к реплике для чтения?». Мы всегда отвечали одинаково: платформа не поддерживает чтение с реплик, и добавлять такую возможность мы пока не планируем.

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

SQL-запрос выполнился без ошибок, дашборд обновился, цифры выглядят правдоподобно — и всё же выручка внезапно выросла на треть. Причина может скрываться в одном JOIN, незаметном NULL или неверной границе периода. Разбираем семь ошибок в SQL-агрегациях, которые не ломают запросы, зато вполне способны сломать выводы из данных.

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

У нас получилось немного иначе.

При подключении нового пилотного контура PostgreSQL к Zabbix выяснилось, что Mamonsu успешно работает с базой данных и собирает метрики, но не может передать их на сервер мониторинга, если тот принимает от узла только защищённые соединения с TLS PSK.

Можно было изменить настройки Zabbix или построить обходную схему вокруг штатного zabbix_sender. Вместо этого мы решили доработать сам Mamonsu. В результате появилась поддержка TLS PSK и сертификатов с сохранением совместимости как со старыми серверными версиями Python, так и с современными версиями Python, где PSK уже поддерживается стандартным модулем ssl.

Доработку проверили на пилотном контуре, после чего отправили разработчикам Mamonsu в upstream.

В 2023 году мы писали о временных таблицах в PostgreSQL и о том, как перенести их на RAM-диск. Это помогло: в наших измерениях доля ext4 в профиле процессора упала с 13,5% до 1,6%, и про диск мы с тех пор не вспоминали. Однако создание, очистка и удаление временных таблиц остались обычным DDL — с изменениями системного каталога и сильными блокировками, которые держатся до конца транзакции. Оказалось, что это отдельная цена, и платить её приходится в самых неожиданных местах.

На одном сервере активные бэкенды периодически застревали в ожиданиях LWLock:LockManager. На другом отставала логическая репликация и накапливался WAL. Выглядело это совершенно по-разному, а разбираться в обоих случаях пришлось в одном и том же: в том, что происходит в PostgreSQL, когда временные таблицы создаются и очищаются тысячами. Начнём с блокировок — там обнаружился массив из 1024 счётчиков, который занимает четыре килобайта, не настраивается и не менялся с 2011 года, и выяснилось, что временные таблицы одной сессии могут лишать обычные запросы всех остальных сессий быстрого пути получения блокировок.

Всем привет!
Я порядка 15 лет занимаюсь администрированием СУБД, а в данный момент работаю на должности старшего инженера по базам данных.

За свою карьеру мне довелось попробовать в работе разные системы мониторинга СУБД, но больше всего мне нравился Spotlight for SQL Enterprise. Это, наверное, лучшая система мониторинга, с которой мне доводилось работать.

К сожалению, Quest Software ушел из РФ, и компании, которые вынуждены соблюдать санкционные режимы, больше не могут им пользоваться. В попытках найти близкие альтернативы я понял, что ничего похожего на рынке нет, и понял: вот она, ниша, в которой можно проявить себя и применить весь свой опыт! :=)

Так появился Lumen.

Сначала — об архитектуре.
Lumen имеет аналогичную архитектуру со Spotlight, есть Diagnostic Server который устанавливается на Windows host. В нем настраиваются подключения к целевому серверу. На целевой сервер ничего устанавливать не нужно, необходимо лишь наличие прав на стороне сервера.

Зимой я разбил две машины с интервалом в пару недель. Никто не пострадал, кроме моего кошелька — и в результате этого курьёзного случая мне очень понадобились деньги.

В январе 2026 я вышел на рынок труда искать своего идеального работодателя. Все тестовые задания для SEO-специалиста одинаковы до банальности: провести аудит сайта, написать ТЗ, дать рекомендации. После первого же тестового я понял, что не готов сделать ещё сотню таких. И решил, что помощника проще написать, чем искать, учить, терпеть и оплачивать.

9 января 2026 появилась первая строка кода. Сегодня это Оракул — оркестратор ИИ-агентов: 465 коммитов, ~20 000 строк Python, четыре LLM-провайдера, планировщик, MCP-сервер и первые клиенты. Загрузка по основной работе никуда не делась, так что весь проект — это примерно 4 часа в день.

Ниже — не история успеха, а список из девяти требований, которые я предъявлял к помощнику, и того, во что каждое из них превратилось в коде. Вместе с багами, которые я на этом поймал.

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

Именно здесь появляется Tantor Polar — распределенная СУБД с разделением вычислений и хранения и 100% совместимостью с PostgreSQL. На ее основе построена машина баз данных Tantor XData Gen3, объединяющая мощные вычислительные узлы, высокопроизводительное общее хранилище и высокоскоростную сеть c RDMA в единую систему. В этой статье мы покажем, что эта архитектура дает на практике — рассмотрим устройство синергично работающих программных и аппаратных модулей позволяющих достичь высоких показателей в популярных нагрузочных фреймворках, таких как TPC‑B (250 тыс. TPS) и TPC‑C (2,6 млн NOPM). 

В прошлой статье я рассказывал, как мы перевозили терабайт банковской базы с Oracle на PostgreSQL без даунтайма. Там был раздел про производительность, и в комментариях несколько человек спросили примерно одно и то же: «а что конкретно вы дебажили и как?».

Это продолжение. Три инцидента из двух разных проектов — банковской системы после миграции и enterprise-платформы на Java/Spring, где PostgreSQL жил под Hibernate. Разные домены, разные команды, но сюжет один: запрос, который вчера работал, сегодня не работает, а EXPLAIN показывает, что всё хорошо.

Если вы пришли в PostgreSQL из Oracle или из мира, где база — это «то, куда ORM пишет», три четверти статьи будут про вещи, о существовании которых вы не подозревали. Я тоже не подозревал.

Дисклеймер: проекты под NDA, названия, объёмы и часть деталей изменены. Порядок величин и сами инциденты — настоящие.

Что, если индекс не нужно создавать вообще? Знакомимся с iHeap — альтернативным методом доступа к таблицам PostgreSQL, где BRIN-индексирование встроено «из коробки» и работает автоматически для всех подходящих столбцов.

Раскатка обновлений INTEKEY WMS больше не зависит от того, у кого сегодня открыт SSH и кто помнит, какая сборка где стоит. Мы создали оркестратор, который берёт на себя весь цикл: сборку, проверки, раскатку по стендам, точки отката и отчётность. Ниже как он устроен.

Как я собрал бесплатный сервис метаданных книг на Java и Spring Boot — с EAV/Pivot-схемой БД вместо ALTER TABLE на каждое новое поле, агрегацией нескольких открытых источников. Плюс обновлённый плагин для Obsidian.

pg_anon — полностью открытый инструмент для PostgreSQL, который ищет персональные данные по заданным правилам и выгружает копию базы уже замаскированной. За год проект заметно вырос: частичный дамп и восстановление, поддержка сложных схем, REST API, новый CLI. В статье разбираем все режимы на реалистичной демо-базе.

Что делать, если WAL удалён, сервер убит kill -9, база после pg_resetwal не хочет открываться, а бизнес стоит уже сутки? Это не гипотетический вопрос, а реальный кейс с кластером PostgreSQL для 1С на 2,5 терабайта данных. Расскажем историю о том, как без бэкапов, без WAL-архивов и почти без надежды вытащили критичные данные 1С-инфобазы. А в конце — неожиданный поход в апстрим PostgreSQL с патчем для pg_dump.