All templates
ER template
Inventory management ER diagram
Products, stock levels, warehouses, and orders in a supply chain system.
Every ecommerce or supply chain system has to answer the same question: do we have the product in stock, and if so, where is it? This template models the essential relationships: Products and their prices, Stock Levels tracking quantity in each Warehouse, Customer Orders containing Order Items, and Shipments that fulfill those items. The schema separates stock levels by warehouse, so you can see how many units of a SKU exist in each location — critical for deciding which warehouse fulfills each order.
When to use this template
- Building a fulfillment system — architects and engineers can see at a glance how stock is tracked, where reorder logic lives (Stock Levels.reorder_point), and how orders connect to shipments.
- Multi-warehouse strategy discussions — product and ops teams can discuss inventory allocation: which products go to which warehouses, how to handle regional demand, and what happens when a warehouse runs out.
- Database design reviews — the diagram shows why quantity lives in Stock Levels, not Products; why Shipments is separate from Orders; and where to add indexes (product_id on Stock Levels, warehouse_id on Shipments).
How to adapt it
Extend the schema to match your operations:
- Add a Suppliers table and a Purchase Orders table to track incoming stock and restock lead times — Warehouses receives purchase orders when Stock Levels falls below reorder_point.
- Insert a Fulfillment Events table with timestamps (picked, packed, shipped, delivered) so you can track the journey from warehouse to customer.
- Add a Locations entity if warehouses have multiple shelves or bins — Stock Levels then references both a warehouse and a location within it.
Visual edits regenerate clean Mermaid code, so you can refine the schema with your team and drop it into your database documentation or system design docs.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
erDiagram
PRODUCTS ||--o{ STOCK_LEVELS : tracks
STOCK_LEVELS }o--|| WAREHOUSES : "stored in"
WAREHOUSES ||--o{ SHIPMENTS : dispatches
ORDERS ||--o{ ORDER_ITEMS : contains
ORDER_ITEMS }o--|| PRODUCTS : "requests"
SHIPMENTS }o--|| ORDER_ITEMS : fulfills
PRODUCTS {
int product_id PK
string sku
string name
decimal price
}
STOCK_LEVELS {
int stock_id PK
int product_id FK
int warehouse_id FK
int quantity_on_hand
int reorder_point
}
WAREHOUSES {
int warehouse_id PK
string name
string location
}
ORDERS {
int order_id PK
int customer_id FK
timestamp created_at
string status
}
ORDER_ITEMS {
int order_item_id PK
int order_id FK
int product_id FK
int quantity
}
SHIPMENTS {
int shipment_id PK
int warehouse_id FK
int order_id FK
timestamp shipped_at
}
Frequently asked questions
- What does an inventory management ER diagram show?
- It maps the core entities in a supply chain system: Products (what you sell), Stock Levels (how many units you have of each product in each warehouse), Warehouses (where stock is stored), Orders (customer requests), Order Items (the products in each order), and Shipments (fulfillment from warehouse to customer). Arrows show relationships — for example, Stock Levels tracks which warehouse holds how many units of each product, and Shipments fulfill Order Items.
- Why separate Stock Levels from Products?
- Because the same product can exist in multiple warehouses with different quantities. If you stored quantity directly on the Product table, you'd have one number per product, not per warehouse. The Stock Levels table lets you track quantity-on-hand and reorder thresholds independently for each product-warehouse combination, which is essential for multi-location fulfillment.
- What is a reorder point and why is it in the database?
- The reorder point is a quantity threshold — when on-hand stock falls below it, it's time to purchase more. Storing it in the database lets your system automatically trigger a purchase order or alert the warehouse manager. Different products have different reorder points: fast-moving items might reorder at 100 units; slow-moving items at 10.
- How do I extend this diagram to handle backorders or multi-step fulfillment?
- For backorders, add a relationship from Orders to a Backorders table tracking unfulfilled quantity and expected restock date. For multi-step fulfillment (pick, pack, ship), add a Fulfillment Events table with a timestamp and status for each stage. Both fit naturally and keep the core ER diagram readable.