IBM IMS and the Hierarchical Database Model Before Relational Systems
IBM's IMS grew from an Apollo-era parts-tracking problem into a durable hierarchical database and transaction-processing system, illustrating both the strengths and constraints of navigational data models before relational databases.
Before relational tables, databases were often navigated as structures
Modern database users are accustomed to asking for rows that satisfy a condition without specifying exactly how the storage engine should reach them. That separation between a logical request and a physical access path was not the default in the 1960s. Early database systems commonly exposed hierarchical or network structures in which applications followed known relationships through the stored data.
IBM’s Information Management System, or IMS, became one of the most important examples of the hierarchical approach. Its history also shows why early database architecture was shaped by concrete engineering problems rather than by an abstract search for a universal data model.[1]
IMS grew out of the Apollo program’s bill-of-materials problem
IBM records that work on the system began in the 1960s to help North American Aviation and the Apollo program manage very large bills of material and engineering changes. An IBM, Rockwell and Caterpillar team began designing the system in 1966; the first release was shipped in 1967 and installed in 1968.[2]
The original system was called Information Control System and Data Language/Interface, or ICS/DL/I. IBM later commercialized the technology as IMS for System/360.[1]
The first problem was not ad hoc analytics
The engineering task favored predictable relationships: assemblies contained subassemblies, which contained components, with paths that naturally resembled a tree. A hierarchical representation could be extremely efficient when the application’s access routes were well understood in advance.
That is an important historical boundary. IMS was not a failed attempt at a relational database. It was a successful answer to a different set of constraints.
The hierarchy made parent-child relationships explicit
IBM describes the IMS database component as centered on a hierarchical data model. Records are arranged in tree-like relationships, so a program typically reaches a child through its parent rather than treating all records as members of independent tables.[1]
This organization can make known traversals fast and conceptually direct. If an application repeatedly follows the same path through the same structure, storing that path as part of the data model is useful.
Navigation also couples programs to access paths
The cost appears when questions change. If a program is written around a particular route through a hierarchy, a new access pattern may require new code or new pointers. IBM’s own historical account notes that IMS specialists often had to hard-code search instructions through the tree and revise them when structures changed.[1]
DL/I became the programming interface to the hierarchy
The Data Language/Interface layer gave application programs operations for retrieving and updating segments in the hierarchical database. Instead of expressing a declarative relation and letting a query optimizer discover an access plan, the application worked more directly with the database’s navigational structure.
This distinction—navigation versus declaration—would become one of the central fault lines in database history.
Hardware constraints helped make hierarchy a practical choice
A 1983 retrospective on IMS preserved by the Computer History Museum describes why hierarchy fit the system’s original environment: disk capacity was limited, Apollo data volumes were large, and parts-list and bill-of-material workloads mapped naturally to hierarchical structures. It also notes that GUAM, a predecessor to DL/I, already used the hierarchical model.[5]
The choice was therefore not only conceptual. It reflected the storage economics, access patterns and application requirements of the machines on which IMS was built.
IMS paired data management with high-volume transaction processing
High-volume operational workloads favored known paths
The commercial system was not only a database. IBM also developed IMS as a transaction-processing platform capable of handling large volumes of ordered messages for banking, reservations, manufacturing and other operational workloads.[1]
That pairing helps explain the platform’s longevity. Organizations do not replace infrastructure merely because a newer data model is intellectually cleaner. They replace it when the operational, economic and migration case becomes strong enough.
Codd’s relational model attacked the dependence on storage structure
In 1970, IBM researcher Edgar F. Codd argued that users and application programs should be protected from changes in the internal representation of data. His relational model explicitly criticized systems that exposed tree or network organization as part of the user’s working model.[3]
IBM’s later history of the relational database frames the change similarly: hierarchical systems could require specialized knowledge of paths and pointers, while the relational model aimed to let users work with tables and values instead.[4]
The relational critique did not erase the hierarchical advantage
Hierarchies remain natural for many domains, and modern systems still use tree structures internally. The historical change was not that trees became useless. It was that database users increasingly expected logical data access to be independent from the physical route used to find records.
Why IMS belongs in database history
IMS demonstrates the first great era of database engineering: data structures and application access paths were designed together for predictable, high-value workloads. It also provides the clearest contrast for understanding why the relational model was disruptive.
The transition from IMS-style navigation to relational declaration was therefore not simply a change from one file format to another. It was a change in who had to know the structure of the machine: the application programmer, or the database system itself.
Works Cited
- 01
- 02
- 03
- 04IBM — The relational database ibm.com
- 05Computer History Museum Archive — IMS: Past, Present, Future (1983) archive.computerhistory.org
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead