History of Databases and SQL: from IMS to the relational model

Databases did not start with SQL tables. They evolved from rigid file-based and hierarchical systems into relational systems built around abstraction, constraints, and declarative queries.

This article gives you the historical path that connects early DBMS software, Edgar F. Codd’s relational model, IBM System R, and the standardization of SQL.

If you are new to the topic, start with Introduction to Databases. Then continue with Relational Data Modeling, Relational Normalization, and SQL Index Performance.

Before relational databases

#

In the 1960s and early 1970s, data management systems were tightly coupled to the physical way data was stored. Hierarchical and network systems were powerful for their time, but they came with real limitations.

Typical problems included:

• strong dependence on physical storage structure;
• expensive application rewrites when schemas changed;
• difficult maintenance as datasets grew;
• limited flexibility for ad hoc querying.

A well-known example is IMS (Information Management System) from IBM, originally developed for the Apollo program. Systems like IMS proved that large-scale data management was possible, but they also revealed how costly rigid access paths could become.

Edgar F. Codd and the relational model

#

The major turning point came in 1970, when Edgar F. Codd published A Relational Model of Data for Large Shared Data Banks.

Codd proposed that data should be represented logically as relations instead of being tied directly to tree or graph traversal paths.

That shift changed three things permanently:

1. Structure: data could be represented as tables with attributes and tuples.
2. Integrity: rules could be enforced explicitly through keys and constraints.
3. Manipulation: data could be queried through high-level operations rather than low-level navigation.

This is why the relational model remains the conceptual foundation of modern SQL databases.

Why the relational model won

#

The relational approach solved several business and engineering problems at once.

• It separated logical design from physical storage.
• It made schemas easier to evolve.
• It made query languages more expressive.
• It allowed optimizers to choose efficient access strategies automatically.

Instead of forcing developers to describe exactly how to walk through records, the new model let them describe what data they wanted.

A simple relational example

#

Imagine a relation Album(id, name, artist_id, year).

and a related table Artist(id, name, country).

This separation illustrates one of the key strengths of the relational model: facts are stored where they belong, and relationships are expressed explicitly through keys.

System R and the birth of SQL

#

IBM initially hesitated to abandon its successful earlier systems, but the ideas behind the relational model were too strong to ignore. The result was System R, IBM’s influential research project for relational databases.

System R helped prove that a relational system could be practical, not just elegant in theory. It also gave rise to SQL, the language that would become the dominant interface for relational databases.

SQL was originally connected to names such as SEQUEL and evolved into the standardized language we now use for:

• creating tables;
• reading data with SELECT;
• modifying data with INSERT, UPDATE, and DELETE;
• defining constraints, indexes, and permissions.

What made SQL important

#

SQL spread because it was declarative.

Instead of saying:

• open this file;
• walk this structure;
• follow this physical path;

SQL lets you say:

SELECT product_id, AVG(stars) AS avg_rating
FROM reviews
GROUP BY product_id
ORDER BY product_id;

The DBMS then decides how to execute that request. This separation between logical request and physical strategy is one of the deepest ideas in database history.

SQL standards and adoption

#

As vendors began building relational products, the need for a common language became obvious.

• ANSI standardized SQL in 1986.
• ISO followed in 1987.
• SQL-92 became the baseline many people still use when discussing broad SQL compatibility.

Later editions expanded the language further.

Major SQL standard milestones

#

• SQL:1999 introduced features such as recursive queries and triggers.
• SQL:2003 added important analytic capabilities such as window functions.
• SQL:2011 expanded support for temporal data.
• SQL:2016 strengthened JSON-related functionality.
• SQL:2023 added newer features for modern workloads, including areas such as property graph support and multidimensional arrays.

In practice, vendors implement these standards unevenly, but the standards still matter because they shape the common language and vocabulary of the ecosystem.

Commercial and open-source adoption

#

By the 1980s and 1990s, relational systems became dominant through products such as:

• IBM DB2
• Oracle Database
• Ingres
• Microsoft SQL Server
• later PostgreSQL, MySQL, SQLite, and many others

The relational model became the default mental framework for business software, transactional systems, and large parts of analytics.

Why this history still matters

#

Database history is not just trivia. It explains why modern DBMSs are designed the way they are.

• We model entities and relationships because the relational model made logical structure explicit.
• We use normalization because storing one fact in one place reduces anomalies.
• We use SQL because declarative querying scales better than hand-coded traversal.
• We use indexes and optimizers because physical access paths still matter, even when users do not describe them manually.

FAQ

#

Who invented the relational model?

#

Edgar F. Codd proposed it in 1970 while working at IBM.

Where did SQL come from?

#

SQL grew out of IBM’s relational research, especially the System R project.

Why did relational databases replace earlier systems?

#

Because they offered better abstraction, easier querying, greater flexibility, and stronger separation between logical structure and physical storage.

Are SQL standards fully identical across vendors?

#

No. Vendors follow the standards to different degrees, but the standards still provide a shared foundation.

Next step

#

If the historical picture is clear, continue with Relational Data Modeling to see how relational ideas become actual tables, keys, and relationships.