PostgreSQL for WMS: a DBMS selection strategy in the era of import substitution

Choosing a Database Management System (DBMS) for Warehouse Management Systems (WMS) transcends mere technicalities; it embodies a strategic decision that influences the security, budget, and future adaptability of your business. This discourse is not about the technical superiority of PostgreSQL but rather its emergence as the singular safe, cost-effective, and future-proof solution for Russian warehouse systems in our evolving landscape.

This narrative serves as a guide for those who wish to avoid the pitfalls of a paralyzed warehouse and the potential for substantial fines stemming from past missteps. At INTEKEY, we have navigated this path thoughtfully, implementing PostgreSQL in our WMS projects for leading market players. Our experience has illuminated the challenges and how to circumvent them.

The New Reality

The landscape post-2022 is one that many are familiar with: a significant withdrawal of foreign vendors, including major players like Oracle and Microsoft SQL Server. This shift brings with it not just inconveniences but systemic risks that many continue to overlook, clinging to outdated licenses in hopes of maintaining the status quo. Companies, particularly state-owned entities, banks, and large enterprises, now face a critical choice: remain on precarious legacy solutions that disregard MinTsifry registry mandates and regulatory standards from FSTEC and FSB, or forge a new path. We firmly believe that for warehouse systems, the only viable option is PostgreSQL and its commercial derivatives. This conviction is not blind faith in open-source technology; it is a calculated decision grounded in risk assessment and opportunity analysis, where the right strategic choice aligns with practical needs.

Why Not Oracle? Three Key Risks That Turn a License into a “Time Bomb”

Let us be candid: continuing to utilize foreign DBMSs is not merely conservative; it poses a direct threat to business continuity. It is akin to constructing a warehouse on unstable ground that could collapse at any moment.

Regulatory Risk: Why Critical Infrastructure Is Not “Someone Else” — It Is You

The shutdowns of Jira and Confluence are not mere cautionary tales; they set a precedent. The implications for critical infrastructure are far more severe than they appear. Many believe, “We are not critical infrastructure; this does not concern us.” This is a perilous misconception. Consider the following:

• Starting September 1, 2025, the use of foreign software in government bodies and companies with over 50% state ownership will face legal restrictions. If you partner with these entities, your WMS on Oracle could hinder your business operations.
• Your status can change. The criteria for being classified as critical infrastructure are expanding. Today, you may not be classified as such, but tomorrow your entire sector could fall under new regulations. A notable example is the draft law that equates ERP systems with critical infrastructure, positioning WMS as a likely candidate for future inclusion.
• The regulatory trend is evident. The state is consistently tightening software requirements. Choosing Oracle today introduces a direct regulatory risk, and an urgent migration may soon become necessary, incurring substantial costs and operational disruptions.

Financial Risk. The exorbitant licensing fees associated with Oracle are no longer a “cost of reliability” but rather a “tribute to a fading era.” Investing millions in technologies that could be legally prohibited tomorrow is both shortsighted and economically unwise. We have witnessed invoices reaching tens of millions of rubles for licenses that businesses felt compelled to pay merely to “avoid rocking the boat.” However, the boat is already taking on water, and patching it with cash is a questionable strategy.

Business Continuity Risk. The potential for unilateral cessation of support, security updates, and critical bug fixes by the vendor is a stark reality. What will you do when a vulnerability is discovered in your operational warehouse and there is no one available to address it? Or when a new operating system update necessitates a DBMS patch that you will never receive? This is not a hypothetical scenario but a tangible threat that numerous companies have already encountered.

PostgreSQL: From Open-Source to a New Enterprise Standard

What is PostgreSQL today? It is not merely a “free replacement”; it is a robust, full-featured open-source DBMS with a thriving Russian ecosystem. Over the years, we have rigorously tested it in real-world projects, managing hundreds of concurrent connections and terabytes of data.

Currently, the choice is between two primary paths, both leading toward independence:

• Vanilla PostgreSQL. This is a solid baseline option for most standard tasks and small to mid-sized WMS projects. It is free, open, and possesses all the necessary functionality for warehouse systems with moderate data volumes and loads. Its development is supported by a global community of developers, as well as a sizable Russian-speaking community that actively shares practices, extensions, and solutions tailored to local needs. For many projects of this scale, it is more than sufficient.
• Commercial Forks (e.g., Postgres Pro). These are tailored versions equipped with unique features, horizontal scaling (sharding), and comprehensive enterprise support. They occupy the niche previously held by Oracle and MS SQL Server, and importantly, these are Russian companies that will remain in the market and continue to provide support.

Enterprise Level: When Vanilla PostgreSQL Is Not Enough

While vanilla PostgreSQL is a capable solution, it does have its limitations. Our experience indicates that under high load with data volumes exceeding 3 TB, the standard version may begin to falter. Large operations, such as mass inventory in extensive warehouse zones or optimizing routes for numerous pickers simultaneously, can become unacceptably sluggish.

Product Director at Postgres Professional, Artem Galonsky: “The Postgres Pro family was originally designed for serious workloads. That is why they are actively used by large state and private customers. In particular, we managed to handle large data volumes in the GIS GMP database, which stores transactions of the Russian Treasury. Load testing proves our developments are ready for high loads both in volume and in data processing speed.”

What Does Postgres Pro Offer?

• Deep Kernel Changes. The Postgres Pro codebase is more than twice the size of vanilla PostgreSQL due to optimizations and customizations for extreme loads. Enhancements to index mechanisms, the query planner, and caching systems yield a 2-3x performance boost for typical WMS operations (receiving, picking, inventory).
• Sharding. For extreme loads, Postgres Pro Shardman provides a ready solution. It has been experimentally proven that a petabyte of data can be accommodated within a sharded cluster, paving the way for systems with virtually unlimited capacity. Imagine a WMS for a federal network where the movement history of every item is preserved for years and available for real-time analytics—this is no longer science fiction.
• Optimization for 1C. Postgres Pro Enterprise takes into account the specificities of this platform, which is crucial for many Russian companies where 1C is the predominant accounting system.

WMS and PostgreSQL: Technical Requirements and How They Are Met

What does a WMS require from a DBMS? It is not merely about data storage; it is about ensuring 24/7 operation with very high transaction intensity. A delay of mere fractions of a second during receiving can lead to accounting discrepancies, while sluggishness during picking can disrupt shipment schedules and incur penalties. Here are the key takeaways from numerous successful implementations:

• Version Matters: Why You Cannot Skimp on Being Up to Date. The minimum threshold is PostgreSQL 14. This is not a whim but a necessity: this version introduced optimizer and indexing features that are critical for modern WMS. We strongly recommend using the latest stable versions (15, 16). Why? Because we have witnessed the difference. In one project, a simple upgrade from version 12 to 14 resulted in a 15% speed boost for complex turnover reports—no code changes, just internal DBMS enhancements.
• The Three Pillars of Performance: Parameters That Decide Everything.
  • max_connections: Exceeding this limit results in a queue. Aim for 100 connections or more. Each warehouse worker’s web session, each handheld terminal connection, and each background process counts as a separate connection. Underestimating this parameter during peak hours guarantees delays and “freezes.” We always calculate it with a 2x margin.
  • shared_buffers: The golden rule is 25% of RAM. Our WMS aggressively caches reference data (SKU catalog, bins) and current stock. Insufficient buffers lead to constant disk access, drastically reducing performance. It is akin to working with data from a slow hard drive instead of fast RAM.
  • work_mem: A seemingly minor detail that can have a significant impact. Set this value to a minimum of 64 MB. Our platform frequently sorts and hashes data: when building routes, forming picking tasks, and generating reports. Inadequate memory forces operations to disk. We have observed that increasing work_mem from 4 MB to 128 MB reduced the time for a critical stock report from 3 minutes to just 10 seconds. This is not mere optimization; it represents a fundamentally different level of responsiveness.

Why We Trust PostgreSQL for Industrial Operations

Our confidence in PostgreSQL is not merely theoretical; it is rooted in its reliable architecture. The capability to configure hot replicas for redundancy is not an optional feature but a fundamental requirement for any critical warehouse. Tools like the pg_stat_statements extension are invaluable in identifying and resolving bottlenecks. This extension allows us to optimize slow queries effectively, maintaining high performance as projects expand.

Looking Ahead: Advanced Capabilities for Modern WMS

A contemporary WMS is no longer just an accounting system; it serves as a data center for management decisions. The PostgreSQL ecosystem offers solutions that competitors simply cannot match.

• Real-Time Analytics. Solutions like Postgres Pro AXS and Angri enable complex analytical queries to run directly on the operational database without the need to export data to a separate warehouse. This means that managers can monitor not only current stock levels but also sales trends, forecast peak loads, and allocate resources in real-time.
• Vector Databases and AI. This is not a distant future; it is on the horizon. Modern warehouses require not just accounting but also analytics, forecasting, and intelligent search capabilities. Traditional DBMSs struggle with vector representations utilized in neural networks.

Product Director at Postgres Professional, Artem Galonsky: “We are actively developing this direction. We already have modules that enable you to work with vector data directly within Postgres Pro—without transferring logic to separate services or deploying specialized vector DBMSs. This opens doors for intelligent WMS and related warehouse and supply chain management systems. What this means in practice includes:

• Intelligent Search Across the Product Catalog. For instance, “find all products similar to this one” by meaning (semantics), rather than by exact text match. This is particularly crucial for warehouses with extensive assortments where items may have different names and descriptions may be incomplete or inconsistent.
• Automatic Classification of Products and Documents Using Neural Networks. The system can learn to categorize items by image, description, or a combination of features, subsequently applying routing, placement, and data quality rules.
• Internal Chatbots and Assistants for Employees. These can provide answers to queries such as “How many units of item X are in zone A?” or “Which positions frequently end up mismatched?” using natural language, with access to data and business logic within the system.

The key takeaway is that we are developing data analytics to address the common issue of disparate solutions, where the operational DBMS, data marts, and BI layers exist separately, necessitating complex integration and data duplication. Our approach allows a single DBMS to not only reliably store transactional data but also to conduct research and analytics on the same data, paving the way for a unified ecosystem that merges OLTP and OLAP functionalities. The result is a dual capability: transactional reliability alongside intelligent functions and analytical integrity within a single platform.

Practical Steps: What to Focus on When Choosing and Migrating

How can you make the right decision without succumbing to hype or conservative fears? We have developed a clear algorithm based on numerous successful migrations:

• When to Choose “Vanilla” PostgreSQL? For standard WMS applications with medium data volumes (up to 15-20 TB), particularly when budget constraints exist and in-house expertise is available for support. It serves as a reliable and cost-free foundation.
• When Should You Consider Postgres Pro? For large enterprise solutions, complex analytics, extreme data volumes (>20-30 TB), and when you require Russian 24/7 support. If downtime is not an option and guaranteed vendor response time is essential, this is the route to take.

Decision Checklist

1. Estimate Data Volumes and Peak Load. Calculate not only current but also projected volumes for the next 3-5 years. Analyze peak load periods—the “X hour” when 100+ pickers are working simultaneously and mass receiving is underway.
2. Check Legal Requirements. Ensure that the chosen solution complies with your industry’s requirements and the MinTsifry registry. For public sector entities and related industries, this is not merely a recommendation but a legal obligation.
3. Calculate TCO for 3-5 Years. Factor in not only licensing costs (if applicable) but also support expenses, updates, customization, and administrative salaries. Compare this with the TCO of your current solution. You may be surprised at how “free” Oracle truly is.
4. Request Documentation and Test Environments. Nothing replaces hands-on testing with your data and typical operations. Ask the vendor for a test environment and conduct load testing that simulates your busiest days.