Open Tech for Smart Manufacturing

Insights, tutorials, and open-source tools for the factories of the future

Thursday, August 20, 2026

How to Design a Manufacturing Database with PostgreSQL

How to Design a Manufacturing Database with PostgreSQL

Build the data model behind a Smart Factory before writing complex SQL.

In the previous article, we introduced Industrial SQL through a fictional manufacturing environment. We saw that production orders, machines, production events, downtime, quality, maintenance, and energy data are connected. In this article, we take the next step: designing the relational database that makes those connections possible.


1. Why database design matters in a Smart Factory

A manufacturing system can generate thousands of records every day. But storing data is not enough. We need a structure that allows us to answer industrial questions reliably.

  • Which production line produced a given order?
  • Which machines belong to that line?
  • Which machine generated a production event?
  • How much downtime did the machine experience?
  • Which quality inspection belongs to a production order?
  • How much energy did a machine consume?

These questions require relationships between tables. That is the fundamental idea behind a relational manufacturing database.


2. Start from the manufacturing process

Before creating tables, start with the physical process.

Production Line → Machine → Production Event

Machines also generate downtime events, maintenance events, and energy measurements.

Production orders form another branch:

Product → Production Order → Production Event / Quality Inspection

This process-oriented view helps us identify the entities that should become database tables.


3. The nine core entities

  1. production_lines
  2. machines
  3. products
  4. production_orders
  5. production_events
  6. downtime_events
  7. maintenance_events
  8. quality_inspections
  9. energy_consumption

Each table represents a specific business entity or event rather than mixing everything into one giant table.


4. Production lines and machines

A production line contains industrial machines. This creates a one-to-many relationship:

One production line → many machines

production_lines
-----------------
line_id       PRIMARY KEY
line_code
line_name
location
is_active

machines
--------
machine_id    PRIMARY KEY
line_id       FOREIGN KEY
machine_code
machine_name
machine_type
install_date
is_active

The line_id in machines points back to production_lines. We therefore do not need to repeat the complete production-line information for every machine.


5. Products and production orders

products
--------
product_id      PRIMARY KEY
product_code
product_name
standard_cycle_time_sec
is_active

production_orders
-----------------
order_id          PRIMARY KEY
line_id           FOREIGN KEY
product_id        FOREIGN KEY
order_date
planned_quantity
actual_quantity
rejected_quantity
status

A production order references both a production line and a product. This lets us analyze planned quantity, actual quantity, rejected quantity, product, and line.


6. Production events

Manufacturing systems are event-driven. Machines continuously generate observations.

production_events
-----------------
event_id
order_id
machine_id
event_timestamp
quantity_produced
quantity_rejected
cycle_time_seconds

An event connects several dimensions: when did it happen, which machine, which production order, and what was produced?


7. Downtime and maintenance

Machine availability is a critical manufacturing dimension.

downtime_events
---------------
downtime_id
machine_id
start_time
end_time
downtime_type
reason

Maintenance is modeled as a separate event table:

maintenance_events
------------------
maintenance_id
machine_id
maintenance_type
start_time
end_time
description
parts_cost
labor_cost
total_cost

A machine can therefore experience many downtime events and many maintenance interventions during its lifetime.


8. Quality inspections

quality_inspections
-------------------
inspection_id
order_id
machine_id
inspection_date
inspected_quantity
passed_quantity
failed_quantity
defect_category

Quality is connected to production rather than stored as unrelated information. We can investigate reject rates by machine, product, production order, or line.


9. Energy consumption

energy_consumption
------------------
energy_id
machine_id
measurement_time
energy_kwh
avg_power_kw

This structure allows analysis of energy consumption over time and by machine or production activity.


10. The complete relational model

How to Design a Manufacturing Database with PostgreSQL


Production Lines

      │
      └── Machines
            ├── Production Events
            ├── Downtime Events
            ├── Maintenance Events
            └── Energy Consumption

Products
   │
   └── Production Orders
           ├── Production Events
           └── Quality Inspections

The key idea is simple: the manufacturing domains are connected instead of being treated as independent datasets.


11. Primary keys and foreign keys

A primary key uniquely identifies a row:

machine_id PRIMARY KEY

A foreign key creates a relationship with another table:

line_id REFERENCES production_lines(line_id)

Together, primary keys and foreign keys allow PostgreSQL to represent the structure of the manufacturing system.


12. Why not put everything into one table?

A single table containing machine, production, downtime, maintenance, quality, and energy data would quickly create duplicated data, difficult updates, sparse columns, and unreliable analytics.

A relational model separates entities and connects them through keys. The result is easier to maintain and much more powerful for SQL analysis.


13. Your database design challenge

  1. What is the primary key of each table?
  2. Which tables reference machines?
  3. Which tables reference production_orders?
  4. How would you calculate total production by machine?
  5. How would you connect downtime with production performance?
  6. How would you connect quality results with a production order?

If you can explain these relationships, you are ready for more advanced Industrial SQL.


14. Explore the Smart Factory SQL project

The free learning repository contains the project structure, schema resources, sample data, starter queries, and investigation challenges.

→ Explore the Smart Factory SQL repository on GitHub

💰 Get the Complete Smart Factory Dataset

PostgreSQL 17 database dump, complete CSV datasets, generator SQL, data dictionary, database schema, starter queries and industrial investigation challenges.

Smart Factory Manufacturing Dataset v0.1 — $9

👉 GET THE COMPLETE DATASET ON GUMROAD


What's next?

Now that the relational model is understood, we can start using SQL to investigate production performance.

In the next article, we will analyze planned versus actual production and build our first manufacturing KPI queries.

The goal: use SQL to turn manufacturing data into operational insight.

No comments:

Post a Comment

Post Top Ad

Your Ad Spot

Pages