За последний год в нашей практике заметно выросло число запросов на внедрение Битрикс24 на PostgreSQL от клиентов.

Причины понятны: - курс на импортонезависимость - использование PostgreSQL как корпоративного стандарта в компании - требования служб ИБ и внутренней архитектуры - высокая нагрузка и большие объемы данных

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

1️⃣ Поиск в CRM и смарт-процессах

На одном из проектов пользователи жаловались, что часть записей невозможно найти через поиск.

После длительной диагностики выяснили, что проблема воспроизводится на значениях со сложными артикулами и кодами, содержащими дефисы. Запись существует, но поиск ее не возвращает.

Причину локализовали на уровне работы поискового индекса PostgreSQL. Без погружения в логи и код найти источник проблемы было бы крайне сложно.

2️⃣ Смещение времени в Открытых линиях

Еще один интересный кейс — время сообщений в чатах отличалось от фактического на несколько часов.

Проверили сервер, PHP, БД, настройки пользователей и браузеры. Источник оказался в особенностях обработки timestamp внутри PostgreSQL-драйвера. На поиск причины ушло больше времени, чем на само исправление 🫠

3️⃣ Не весь функционал доступен

С этим столкнулись сами при подготовке одного из проектов. Заказчик планировал использовать штатный BI Конструктор Битрикс24, но оказалось, что для PostgreSQL-редакции он пока недоступен.

Хорошая новость: по информации от вендора поддержка ожидается уже осенью.

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

А в план внедрения сразу закладывайте дополнительное время на диагностику и тестирование — практика показывает, что именно там скрываются неочевидные нюансы.

А какой опыт работы с PostgreSQL-редакцией Битрикс24 был у вас? Сталкивались с багами, ограничениями или особенностями?