The relational model against the alternatives it actually had

1970Codd, in the Communications of the ACM

The paper that introduced the relational model is short, and its argument is not about tables. It is about a property it calls data independence: that a program asking a question should not have to know how the answer is stored.

That framing tells you what it was written against. The systems in use required a program to know the storage layout, because asking a question meant walking it.

1966 to 1971The systems it was written against

Two families dominated. One arranged records in a strict tree, so a query meant descending from a root. The other allowed arbitrary links between record types, and a query meant following named chains from one record to the next.

Both worked, both were fast, and both were standardised by serious committees. In both, a query was a program: find this owner, follow this set, take the next member, test a field, repeat.

1960s and 1970sWhat that cost

The cost was not performance. It was that every program encoded the physical arrangement of the data.

Adding an index, splitting a record, or changing which chain was primary meant revisiting every program that navigated it. In an organisation with hundreds of such programs, the storage layout became effectively frozen, and the database outlived every reason for the shape it had.

1970sThe objection, which was correct at the time

Stating a condition instead of a path requires something to work out the path, and in 1970 nothing could do that well.

Practitioners objected that a hand-written navigation would always beat a generated one, and for the hardware of the period they were right. The argument was public and unresolved for most of a decade, with the two positions defended by people who both later received the discipline's highest award.

1974 to 1979What settled it

Two research systems, one at a manufacturer and one at a university, demonstrated that a query optimiser could be built well enough. Not better than a careful human, but close enough that the human's advantage stopped being worth what it cost to maintain.

That is the shape of the win. The declarative model did not defeat the navigational one on its own ground. It waited until the ground moved: hardware got faster, optimisers got adequate, and programmer time got expensive.

1970s onwardsWhat arrived instead of the model

The language that carried the idea into practice is not a faithful implementation of it, and the paper's author said so at length. Tables may contain duplicate rows, which relations may not. Order is visible where it should not be. A value meaning unknown was added, and it behaves in ways that produce a three-valued logic most users never consciously agreed to.

So the thing that won is a commercial compromise wearing the name of a mathematical model, and the gap between them is the source of a steady supply of surprising query results.

1974The debate, held in public

The disagreement was not conducted in private. It was staged as a formal debate at a conference, with the two models defended by their principal advocates in front of the people who would have to choose between them.

Reading the positions now, the striking thing is that neither side was arguing about correctness. Both models could represent the same data. The argument was entirely about which costs an organisation should prefer to pay: machine time, or the labour of changing programs whenever storage changed.

1970s to 1980sWhy the answer changed rather than being found

The price of machine time fell continuously through the period, and the price of skilled labour did not. An argument settled by the relative cost of two resources gets re-settled whenever that ratio moves, and this one moved in one direction for thirty years.

Which is worth carrying into current arguments of the same shape. Any position that rests on hardware being expensive relative to people has a shelf life, and the people holding it are usually not the ones who notice it expiring.

present dayThe optimiser as the actual product

What a modern database sells is mostly the component the 1970 argument said could not be built well: the thing that reads a stated condition and decides how to satisfy it.

It is also where the abstraction leaks. Practitioners spend considerable effort persuading optimisers toward particular plans, which is navigation returning through the back door, expressed as hints, index design and query rewriting rather than as explicit traversal.

2000s onwardsThe argument returning

The navigational model came back, without the name, as document and graph stores. The pitch was the original one in reverse: for these access patterns, following a link directly beats asking a general engine to work it out.

And the cost returned with it. Applications that store documents encode the shape of their data in the code that reads them, which is precisely the coupling the 1970 paper set out to remove. Both generations were right about their own workload and wrong to generalise.

What we cannot verify

The paper, the competing standards and the research systems are all published and can be read directly. Accounts of how the debate was settled inside particular companies rest largely on later recollection by participants. Performance comparisons from the period were run on hardware and workloads that no longer exist and should not be carried into any modern argument.