PostgreSQL для WMS: стратегия выбора СУБД в эпоху импортозамещения
Выбор СУБД для системы управления складом (WMS) сегодня — это не просто технический вопрос. От него напрямую зависят:
- безопасность и соответствие требованиям регуляторов;
- совокупная стоимость владения ИТ‑ландшафтом;
- гибкость и масштабируемость складской логистики в будущем.
Мы в INTEKEY прошли этот путь осознанно: все новые проекты INTEKEY WMS для крупных российских заказчиков работают на PostgreSQL и его коммерческих редакциях. В этой статье делимся нашим подходом к выбору СУБД для WMS в условиях импортозамещения и усиливающихся требований к критической инфраструктуре.
Импортозамещение и КИИ: новые требования к СУБД для WMS и систем управления складом
После 2022 года рынок СУБД в России радикально изменился: массовый уход иностранных вендоров, в том числе Oracle и Microsoft SQL Server, превратил привычные решения из «надёжной классики» в источник стратегических рисков.
Речь не только об удобстве техподдержки. Компании, особенно в госсекторе, банках, критической инфраструктуре и крупном бизнесе, фактически оказались перед выбором:
- оставаться на старых, но рискованных решениях, игнорируя не только требования реестра Минцифры, но и ограничения для объектов КИИ, а также стандарты ФСТЭК и ФСБ по работе с данными;
- или выстраивать архитектуру на базе технологий, которые соответствуют российскому правовому полю и могут развиваться долгосрочно.
Для WMS‑систем, которые часто попадают в контуры критически важной инфраструктуры, мы видим устойчивый вектор: PostgreSQL и его коммерческие форки. Это не про «модный open source», а про рациональный баланс риска, стоимости и возможностей.
Почему Oracle и другие иностранные СУБД опасны для WMS и складской логистики в России
Законодательный риск
Истории с отключением Jira и Confluence показали, что даже популярные корпоративные продукты могут быть одномоментно недоступны. В случае с СУБД последствия будут куда серьёзнее.
Важно учитывать:
- с 1 сентября 2025 года использование иностранного ПО в госорганах и компаниях с госучастием более 50% законодательно ограничено;
- Критерии отнесения к объектам КИИ постепенно расширяются — сегодня система не считается критической, завтра отрасль может попасть под новое регулирование;
- Уже сейчас обсуждаются инициативы по приравниванию ключевых систем (ERP, возможно и WMS) к элементам КИИ.
Продолжать строить новые WMS на Oracle или других зарубежных СУБД в таких условиях — сознательно принимать на себя законодательный риск и вероятность экстренной миграции «под давлением обстоятельств».
Финансовый риск
Высокая стоимость лицензий на иностранные СУБД перестала быть «ценой за надёжность». В ситуациях, когда технология может быть ограничена или запрещена в любой момент, дальнейшие вложения в такие продукты становятся экономически сомнительными.
Мы видели счета на десятки миллионов рублей только за продление лицензий, которые компании оплачивали, не желая «трогать работающую систему». Но в условиях импортозамещения это больше похоже на обслуживание уходящей платформы с всё более неопределённым горизонтом жизни.
Риск бизнес‑непрерывности
Ещё один аспект — поддержка и обновления:
- Прекращение официальной поддержки;
- Отсутствие критических патчей безопасности;
- Несовместимость с новыми версиями ОС и инфраструктуры.
Вопрос, который нужно задать себе заранее: что будет, если на работающем складе обнаружится уязвимость или критический баг, а получить исправление от вендора уже невозможно? Для WMS это не академический сценарий, а прямая угроза работе склада.
PostgreSQL: от «альтернативы» к новому стандарту
На этом фоне PostgreSQL за последние годы прошёл путь от «бесплатной замены» до фактического enterprise‑стандарта для многих российских систем, в том числе WMS.
Для нас, как разработчика и интегратора INTEKEY WMS, PostgreSQL стал основной платформой данных по нескольким причинам:
- Открытый исходный код и прозрачное развитие;
- Зрелость технологии и подтверждённая стабильность на реальных WMS‑нагрузках (сотни одновременных подключений, терабайты данных);
- Наличие сильного международного и русскоязычного сообщества;
- Развитая экосистема российских коммерческих решений (Postgres Pro и др.), которые закрывают задачи enterprise‑уровня.
Сегодня выбор, по сути, сводится к двум основным вариантам.
«Ванильный» PostgreSQL
Хороший базовый выбор для большинства типовых WMS‑проектов малого и среднего масштаба:
- Бесплатный и открытый;
- Обладает всем необходимым функционалом для складских систем со средними объёмами данных и нагрузкой;
- Развивается силами большого международного и российского сообщества.
Для значительной части проектов такого уровня этого более чем достаточно — при условии грамотной настройки и понимания характерных нагрузок WMS.
Коммерческие форки (на примере Postgres Pro)
Для крупных и высоконагруженных систем, где требования к производительности и масштабированию выше, чем может предложить «ванильный» PostgreSQL, логично смотреть в сторону коммерческих решений на его основе — в первую очередь, Postgres Pro.
Их ключевые особенности:
- Глубокие оптимизации ядра под серьёзные транзакционные и аналитические нагрузки;
- Поддержка горизонтального масштабирования (шардирования), в том числе для очень больших объёмов данных;
- Полноценная enterprise‑поддержка от российского вендора, работающего в нашем правовом поле.
Enterprise‑уровень: когда «просто PostgreSQL» уже мало
У «чистой» версии PostgreSQL есть объективные пределы. Наш опыт внедрения INTEKEY WMS показывает:
- На высоких нагрузках при объёмах от нескольких терабайт и выше стандартная конфигурация может демонстрировать деградацию производительности;
- Большие операции (массовая инвентаризация, сложные пересчёты, расчёт маршрутов для сотен сборщиков) начинают выполняться неприемлемо долго, особенно при параллельной работе множества терминалов.
В таких сценариях на первый план выходят:
- Оптимизированные механизмы работы с индексами;
- Улучшенный планировщик запросов;
- Эффективное использование кэша и памяти;
- Возможность распределять нагрузку по нескольким узлам (шардирование).
Именно для этих задач Postgres Pro предлагает:
- Модифицированное ядро, ориентированное на высокие нагрузки;
- Шардирование (Postgres Pro Shardman) для работы с очень большими объёмами;
- Специальные редакции (например, оптимизированные под 1С), что важно для компаний с единой учётной системой.
Что важно для WMS от СУБД и как это закрывает PostgreSQL
Складская система управления — это не просто «база данных с остатками». Для WMS критично:
- Работа в режиме 24/7;
- Высокая интенсивность транзакций (приёмка, размещение, отбор, отгрузка, инвентаризации);
- Минимальные задержки в ключевых операциях.
Провал даже на доли секунды в момент приёмки или отбора при большом потоке операций способен накапливаться и приводить к расхождениям в данных, срывам отгрузок и SLA, штрафам и потерям клиентов.
Из нашей практики внедрения INTEKEY WMS можно выделить несколько технических принципов.
Версии PostgreSQL
Для современных WMS мы считаем минимально приемлемой версией PostgreSQL 14, а в новых проектах ориентируемся на последние стабильные (15, 16), поскольку:
- Именно в этих версиях появились важные улучшения оптимизатора и индексации;
- Переход на более новые версии нередко даёт прирост производительности «из коробки».
Так, на одном из проектов переход с PostgreSQL 12 на 14‑ю без изменений в прикладном коде дал порядка 15% ускорения ряда сложных отчётов.
Ключевые параметры производительности
Важные настройки, которые сильно влияют на скорость работы WMS:
- max_connections. Недооценка этого параметра в пиковые часы приводит к очередям и «зависаниям» — учитывая, что каждое подключение ТСД, веб‑сессия и фоновый процесс создают отдельное соединение.
- shared_buffers. Рекомендация на уровне 25% от ОЗУ оправдывает себя на практике: WMS активно кэширует справочники и текущие остатки, и при нехватке буфера система начинает чаще обращаться к диску.
- work_mem. Хотя параметр кажется «мелочью», он критичен для операций сортировки и хеширования при построении маршрутов, формировании заданий и отчётов. Мы видели примеры, когда увеличение work_mem с 4 МБ до 128 МБ сокращало время формирования ключевого отчёта по остаткам с 3 минут до 10 секунд.
Отказоустойчивость и мониторинг
Для критичных складских площадок мы считаем обязательными:
- Использование горячих реплик для резервирования и разгрузки чтения;
- Настройку мониторинга и анализ запросов через расширения вроде pg_stat_statements.
Это позволяет своевременно находить «узкие места», прогнозировать нагрузку и планировать развитие инфраструктуры без снижения качества сервиса.
PostgreSQL и расширенные сценарии для современных WMS
Современная WMS всё чаще выступает не только как операционная система учёта, но и как центр данных для принятия решений. Экосистема PostgreSQL открывает дополнительные возможности:
- Аналитика в реальном времени: решения вроде Postgres Pro AXS и Angri позволяют выполнять сложные аналитические запросы по тем же данным, что используются в операционном контуре, без постоянных выгрузок в отдельные хранилища;
- Работа с векторными данными и ИИ‑сценариями: интеллектуальный поиск, автоматическая классификация, чат‑боты и ассистенты для сотрудников склада.
Важно, что всё это возможно на базе единой СУБД, без «зоопарка» разрозненных систем, каждая из которых требует интеграции и синхронизации. Это снижает сложность архитектуры и повышает управляемость решения в целом.
Как выбрать PostgreSQL для WMS и спланировать переход с Oracle/MS SQL
Опираясь на наш опыт миграций и новых внедрений INTEKEY WMS, мы рекомендуем:
- Рассматривать vanilla PostgreSQL для стандартных WMS со средними объёмами данных и нагрузкой, особенно если есть внутренние компетенции по его поддержке;
- Выбирать Postgres Pro или другие коммерческие форки PostgreSQL для крупных enterprise‑решений, экстремальных объёмов данных (десятки терабайт и выше), сценариев с повышенными требованиями по отказоустойчивости и поддержке 24/7.
Перед принятием окончательного решения важно:
- Оценить текущие и прогнозные объёмы данных и пиковые нагрузки;
- Проверить требования законодательства к ПО в вашей отрасли;
- Посчитать совокупную стоимость владения (TCO) на горизонте 3–5 лет;
- Протестировать работу СУБД на ваших реальных сценариях и данных.
Вывод
Для INTEKEY выбор PostgreSQL в качестве базы для WMS — это не разовая техническая ставка, а выстроенная стратегия:
- Соответствие требованиям импортозамещения и КИИ;
- Предсказуемая стоимость владения;
- Подтверждённая на практике производительность под WMS‑нагрузками;
- Возможность по мере роста перейти от «ванильного» PostgreSQL к enterprise‑решениям на базе Postgres Pro без смены технологической платформы.
Если вы думаете о переходе с Oracle/MS SQL на PostgreSQL в контексте WMS — готовы поделиться практическим опытом: от аудита и пилотов до промышленной миграции и сопровождения.
