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