Today's databases carry the mark of successive fixes: each generation answered the flaw of the previous one. This lesson is for anyone who administers or chooses a database and wants to understand where tables, SQL and NoSQL come from, so they can judge a tool without following fashion. It has no prerequisites and applies to every engine.
A DBMS (database management system, also called an "engine") is the software that stores the data and answers the programs that query it; SQL is the standard language for asking it questions. You will see what was stuck before 1970, what Codd, a researcher at IBM, actually proposes, how the model became a product, then what the NoSQL wave of the 2000s gained and lost. Dates and attributions cite their source; where the history is disputed, the lesson says so.
What you will learn
- Explain what was stuck in hierarchical and network databases
- Describe the data independence Codd proposed in 1970
- Credit the relational model and the SQL language to the right people
- Say why an SQL query describes a result and not a path
- Name the problem NoSQL solved and what it gave up in return
How was data stored before the relational model?
Before 1970, a program had to know the physical path to the data it read, and any change in storage layout broke the code. The first systems were hierarchical: IBM's IMS organizes data as a tree of parents and children, like folders stored inside other folders. Released at the end of the 1960s, it was first used to track the parts of the Apollo space program (source: IBM's history page on IMS).
The network model, specified by the DBTG group of the CODASYL consortium in an October 1969 report, allowed freer links between records (the rows of data). But in both cases the program navigated from record to record by following pointers, that is, addresses that designate the next record. Charles Bachman made it the title of his 1973 Turing Award lecture, "The Programmer as Navigator".
Take the incident tracking of a server fleet, the running example of the training. If incidents are stored under their server, the question "all open incidents, all servers combined" requires a purpose-written program that walks every tree. And if you decide to store them under their team rather than under their server, every program has to be rewritten. That rewriting cost is the problem Codd tackles.
What did Codd actually propose in 1970?
Edgar F. Codd, a researcher at IBM's San Jose laboratory, published "A Relational Model of Data for Large Shared Data Banks" in the Communications of the ACM in 1970. His thesis fits in its first sentence: future users of large data banks must be protected from having to know how the data is organized in the machine. He describes data by its natural structure, as relations (what we now call tables, with their rows and columns), without superimposing any machine-specific organization on it.
The paper is a theory: Codd himself states that he does not discuss the implementation of systems. He identifies three dependencies to remove: the dependence on storage order (the program assumes the data is stored in a given order), on indexes (it assumes a given index exists; an index is a side directory that speeds up searching) and on the access path (it assumes a specific route to the data). These are the ones that made programs break.
What is data independence?
Data independence is the separation between how data is stored and how it is queried. Look at the diagram: on the first row, the pre-1970 program writes the physical path to the data itself; on the second, the relational program describes the result it wants and lets the system, the highlighted box, choose the path.
This separation has a concrete consequence: you can add an index, reorganize the files or change servers without touching the queries. This is what you rely on when you speed up an existing search without rewriting the application.
How did the model become a product?
Codd's model stayed a paper until a complete prototype put it to the test. In 1973, an IBM team in San Jose launched the System R project, with among others Donald Chamberlin, Raymond Boyce, Patricia Selinger (a cost-based optimizer) and Raymond Lorie (source: IBM's history page on the relational database). At Berkeley, the Ingres project followed a parallel path, with its own language, QUEL.
IBM launched DB2 in 1983 on mainframe (the big central system of large companies). On the standards side, SQL was standardized by ANSI in 1986, then by ISO in 1987: this is what makes engines more comparable and skills more transferable.
Who invented SQL, and did Codd contribute?
No, Codd did not design SQL. The language, first named SEQUEL, is the work of Donald Chamberlin and Raymond Boyce at IBM, presented in their 1974 paper "SEQUEL: A Structured English Query Language". It was renamed SQL because the name SEQUEL already belonged to another company, according to Chamberlin himself.
Codd had designed his own language, Alpha, described in a 1971 paper. Chris Date, a specialist in the relational model, published a critique of SQL in 1984 that points out several gaps between the language and the model. Writing that Codd designed or developed SQL is therefore a common confusion, not to be copied.
Why is SQL declarative?
A declarative language describes the result wanted, never the method to obtain it. It is data independence turned into a language, and it is only workable because the system knows how to choose by itself. The role of System R's optimizer was precisely to compare the possible paths and pick the cheapest. The language itself is learned in the SQL training (in French); the model in practice, in Data modeling.
Who sold the first commercial relational DBMS?
The question is not settled, and it is better not to settle it. Three sources give three answers. Oracle is a name often cited: IBM writes that the company that would become Oracle produced the first commercially available relational database in 1977, while Oracle's Wikipedia entry places the first version in 1979. But Honeywell's Multics Relational Data Store is cited as commercialized as early as 1976 (June according to the historian Paul McJones, who relies on a September 1976 Computerworld article). The answer changes depending on whether you require SQL, a complete product or a documented sale.
What is established is that several systems existed almost at the same time in the late 1970s. Keep that rather than a "first" title.
Why did NoSQL appear in the 2000s?
NoSQL answers a problem of scale and of schema flexibility (the schema describes the structure of the data; being flexible means not imposing the same one on every record). When web services had to serve millions of users, a single machine was no longer enough and data had to be spread over several machines. Google described Bigtable in 2006 (OSDI conference) and Amazon Dynamo in 2007 (SOSP conference), a key-value store (a value retrieved by its key) designed, writes Werner Vogels, to trade off cost, consistency, durability and performance according to need.
The word NoSQL took its current meaning, according to Wikipedia, at a meetup organized in 2009 by Johan Oskarsson to discuss distributed non-relational databases; Carlo Strozzi had already used it in 1998 for a relational database without an SQL interface. The term covers very different families, described in NoSQL databases (in French).
What these systems traded away: weaker consistency guarantees (not all readers immediately see the same data) in exchange for availability and scalability (serving more users by adding machines). This contract is called BASE and is detailed in Transactions: what ACID and BASE promise. That opposition has since blurred: MongoDB and DynamoDB offer transactions, as the same lesson explains.
Where do databases stand today?
This section ages fast, read it as a snapshot of October 2026. The trend is convergence: relational engines also store JSON, and NoSQL databases add transactions. Cloud providers offer managed databases that take over part of the operations (backups, patches), see Managed data (in French), and specialized engines, such as vector databases (in French), answer specific uses.
Licenses move too, and "open source" can no longer be assumed. In March 2024, Redis announced a license change: starting with Redis 7.4, a dual source-available license (RSALv2 or SSPLv1 at your choice, neither approved by the OSI, the body that defines what open source is, according to Redis itself). The Linux Foundation announced the Valkey fork on 28 March 2024, under the BSD license, branched from Redis 7.2.4. Redis added AGPLv3 with Redis 8, on 1 May 2025. So check an engine's license at the date of your choice.
Key takeaways
- Before 1970, the program knew the physical path to the data: changing the storage layout meant rewriting the code.
- In 1970 Codd proposes data independence: storage and querying are separated.
- His paper is a theory; the complete prototype is System R, at IBM, from 1973.
- SQL comes from Chamberlin and Boyce (SEQUEL, 1974), not from Codd, who had his own language, Alpha.
- SQL is declarative because an optimizer chooses the path in place of the programmer.
- The title of "first commercial relational DBMS" is disputed: do not copy it.
- NoSQL traded consistency for scale and flexibility, and the border with the relational world is blurring.
- A license is checked at the date of the choice: Redis changed in 2024, and Valkey came out of it.
Knowledge check
Eight questions on the problem that pre-1970 databases posed, what data independence changes, who is credited with SQL, why the language is declarative, and what NoSQL traded away.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Data modeling: from the requirement to the relational model
A new full quiz with random questions
Work again only on the questions you missed