A Relational Model of Data for Large Shared Data Banks

idea is right, and proposals.md filed it correctly. The house test for idea, set by shannon-chess-1950 and reused by dijkstra-1959, minimax-alpha-beta and unix-linux-1969-1991, is that there is a mechanism in it you could implement — a framing later work is built out of rather than argued about. This passes twice over: the mechanism is a normal form plus five operators on relations, and there is a working implementation of it inside almost every piece of software anyone reading this has used today.

But the entry is not about databases, and a reading that cites it for databases will cite it badly. What this file records is the only **completed, industrial-scale, fifty-six-year experiment in moving the specification of how from a human to a machine**. A person states what they want; a machine decides the procedure that gets it. That transaction is the thing 2026 argues about constantly — agent autonomy, goal-directed tool use, "just tell it what you want" — and it is not new, it is not untested, and the test finished long enough ago to be graded. Section 3 grades it. The verdict belongs to neither side of the current argument, which is why it is worth having on hand.

Two rival kinds, and why both fail. moment fails on the definition llama-weights-2023 fixed for this canon — a date on which something visibly happened in public. Nothing visible happened in June 1970. A fifteen-page paper appeared in the Information Retrieval section of Communications of the ACM, was read by specialists, and changed nothing for four more years; the first commercial product built on it shipped nine years later, and not from the company that employed the author. prediction is the closer call and it is the one worth arguing, because the paper does contain dated claims about what machines would come to do for people, and section 3 grades seven of them alongside two from the man who publicly disagreed with him. But the paper's centre of gravity is a construction, not a forecast: normalization, the operators, the connection trap. It predicts because it is confident, not because prediction is its purpose. Filed as idea, graded like a prediction, which is the same treatment unix-linux-1969-1991 received and for the same reason.

descends_from is empty, and here that is a checked fact rather than a gap. The paper carries ten references and I read the list off the page. They are: Childs on a set-theoretic data structure (IFIP 1968); Levein and Maron on inference retrieval (CACM, November 1967); Bachman on random access processing (Datamation, April 1965); McGee on generalized file processing (Annual Review in Automatic Programming 5, 1969); the IBM IMS/360 application description manual (July 1968); the IBM GIS manual (1965); Bleier on hierarchical data structures in TDMS (Proc. ACM 22nd National Conference, 1967); the IDS reference manual (GE, February 1968); Church's An Introduction to Mathematical Logic I (Princeton, 1956); and Feldman and Rovner's LEAP, an Algol-based associative language, issued as Stanford Artificial Intelligence Report AI-66, 1 August 1968. None of the ten is in canon/ and none is in proposals.md.

Two of them are worth naming anyway. Church is the predicate-calculus foundation, and the canon holds godel-incompleteness-1931 and turing-halting-1936 from the same intellectual country — but Codd cites neither, so neither is an ancestor and neither should be linked here. And the one artificial-intelligence citation in the paper is cited against: Feldman and Rovner's LEAP came out of the Stanford AI Lab, represented everything as binary relations, and Codd's section 1.5 uses it as the example of what goes wrong when you insist on binary — a 4-ary relation needs seven names instead of five and its interrogation becomes, in his word, "asymmetry." So the first thing this entry does with an AI paper is tell it that it has chosen the wrong representation. If someone later writes bachman-ids-1965 or ims-1968, this header should be edited.

---

What it is

The problem in 1969, in the paper's own terms

The manuscript was received September 1969 and revised February 1970; it ran in Communications of the ACM volume 13, number 6, June 1970, pages 377–387, under the running head "Information Retrieval." Its first two sentences are the whole argument and they are worth having exactly:

> Future users of large data banks must be protected from having to know how the > data is organized in the machine (the internal representation). A prompting > service which supplies such information is not a satisfactory solution.

That second sentence is the one people skip, and in 2026 it is the sharper of the two. Codd anticipated the obvious workaround — let the system tell the user how the data is laid out, and then the user can write the right access — and ruled it out in one line, before proposing anything. Documentation is not data independence. A helpful description of the internal representation still leaves the human doing the navigation; it just makes the navigation better informed. Anyone in 2026 who answers "the model doesn't know our schema" with "put the schema in the context window" is proposing a prompting service, and Codd's objection to it is fifty-six years old and has not been answered. Section 2 takes this up, because it is the most directly transferable sentence in the file.

What the machines of 1969 actually did instead, Codd set out as three dependencies, and the taxonomy is his (§1.2.1–1.2.3):

• Ordering dependence. Files were stored in a total order tied to the hardware address order, and programs assumed that order. Change the order and the programs break. He declined to name a guilty product because there were no innocent ones: "It is unnecessary to single out any system as an example, because all the well-known information systems that are marketed today fail to make a clear distinction between order of presentation on the one hand and stored ordering on the other."
• Indexing dependence. An index is a pure performance artefact — "From an informational standpoint, an index is a redundant component of the data representation" — and yet in the systems of the day, adding or dropping one could break running programs. He asks the question directly: "Can application programs and terminal activities remain invariant as indices come and go?"
• Access path dependence. The one that mattered. The data was stored as a tree or a network of pointers, and a program had to walk it. Codd works the example on page 378: parts, projects, and the quantity of each part committed to each project. He lays out five different hierarchical structures that all faithfully record the same facts, then observes that a program written for one of them fails on at least three of the others — "If P succeeds with structure 5, it will fail with all the others; if P succeeds with structure 3 or 4, it will fail with at least 1, 2, and 5" — and that testing for all of them is impractical. The information is identical in all five. Only the route differs, and the route was the thing the program had been written against.

The proposed fix is one paragraph of mathematics and one paragraph of consequence. A relation is a subset of a Cartesian product; rows are unordered; duplicate rows do not exist; users deal with relationships, the domain-unordered counterpart of relations, so that they need not remember which column comes first. Then normalization: eliminate nonsimple domains by pushing the parent's primary key down into each subordinate relation and flattening the tree. The result, he notes with visible satisfaction, "would be devoid of pointers (address-valued or displacement-valued)," "would avoid all dependence on hash addressing schemes," and "would contain no indices or ordering lists." Everything the program used to navigate by is gone. Nothing is left to navigate.

The sentence where the burden moves

Section 1.5 introduces the piece that made an industry: a universal data sublanguage based on an applied predicate calculus, first-order sufficing so long as the relations are in normal form. Codd is careful about what universal means — "The universality of the data sublanguage lies in its descriptive ability (not its computing ability)" — which is to say it is not a programming language, cannot loop, and is not supposed to. Its whole job is to describe the answer.

That leaves an obvious hole, and the paper walks straight into it. Section 1.6, the last paragraph before the mathematics starts:

> For any selected class of stored representations the data system must provide > a means of translating user requests expressed in the data language of the > relational model into corresponding — and efficient! — actions on the current > stored representation. For a high level data language this presents a > challenging design problem. Nevertheless, it is a problem which must be > solved — as more users obtain concurrent access to a large data bank, > responsibility for providing efficient response and throughput shifts from the > individual user to the data system.

That is the query optimizer, specified in a sentence, nine years before anyone built one. It is also, read at the right angle, the founding charter of every system that takes a stated goal and picks its own procedure. Note the three moves in order: the translation is necessary (the user must not do it), it is hard ("a challenging design problem"), and the responsibility for getting it right shifts from the person to the machine — not because the machine is better at it, but because the person is no longer in a position to do it, there being many of them now and one data bank. The exclamation mark after "efficient" is in the original. He knew what he was handing over.

The half of the paper nobody quotes

Section 2 is longer than section 1 and is almost never cited, which is a pity, because it is where Codd does the thing that distinguishes this paper from a manifesto: he specifies how the model can be checked.

The operators come first — permutation, projection, join, composition, restriction — with the natural join defined in the notation still taught. Then the connection trap, which is the paper's best single piece of engineering prose. Suppose supplier records point to the parts they supply, and part records point to the projects using those parts. It is tempting to conclude that following all the paths from a supplier yields the projects that supplier supplies. Codd shows this is "in general, erroneous": the correct answer is the natural composition of the two relations, and path-following gives it only in a special case. He notes that "a lack of understanding of relational composition has led several systems designers into what may be called the connection trap." An entire class of production bugs, named and explained, in a paper about foundations.

Then redundancy — strong (a relation derivable by an equation from projections of others) and weak (derivable at all times from some join of others, but not by a fixed equation) — and then consistency, with the line that carries the most weight for a project that grades evidence:

> It is important to note that consistency as defined above is a property of the > instantaneous state of a data bank, and is independent of how that state came > about. Thus, in particular, there is no distinction made on the basis of > whether a user generated an inconsistency due to an act of omission or an act > of commission.

The state is checkable without knowing the history. The system does not need to reconstruct intent, or trust the user's account of what they meant; it evaluates the constraint against what is actually there. Codd goes on to sketch three enforcement regimes — check on every insertion, log and notify, or batch the check once a day or less — and notes the first will "slow these operations down." He is trading integrity against throughput on the page in 1970, which is the same trade a 2026 safety monitor makes when it costs a fifth of the inference compute it covers.

The paper closes with an acknowledgment that it was C. T. Davies of IBM Poughkeepsie who convinced Codd of the need for data independence in the first place, and thanks four colleagues at San Jose. The idea has a named origin and it is not the author.

The debate: November 1973 against November 1981

The relational model did not win by being obviously right. It won an argument, in public, against a serious opponent who had the installed base, the standards committee and the Turing Award.

Charles Bachman took the 1973 Turing Award for the Integrated Data Store, the first commercially available database management system, and for his work on the CODASYL Data Base Task Group. His lecture, delivered at the ACM Annual Conference in Atlanta on 28 August 1973 and printed in CACM 16(11), November 1973, is called The Programmer as Navigator, and it is the clearest statement anyone ever made of the position Codd was attacking. Bachman opens on Copernicus — 1973 was the astronomer's five-hundredth birthday — and proposes the same reorientation for data processing:

> There is a growing feeling that data processing people would benefit if they > were to accept a radically new point of view, one that would liberate the > application programmer's thinking from the centralism of core storage and > allow him the freedom to act as a navigator within a database. To do this, he > must first learn the various navigational skills; then he must learn the > "rules of the road" to avoid conflict with other programmers as they jointly > navigate the database information space.

And, with a candour worth preserving: "This reorientation will cause as much anguish among programmers as the heliocentric theory did among ancient astronomers and theologians." His closing proposition is that it is time for the programmer "to abandon the memory-centered view, and to accept the challenge and opportunity of navigation within an n-dimensional data space."

Read it in 2026 and the shape is unmistakable. Bachman is describing skilled human operation of a powerful system whose internals the human must learn — the freedom of the navigator, the navigational skills, the rules of the road, the anguish of the transition, the promise of "effective tools for navigation." It is prompt engineering, argued from the podium, twenty-two years before the web.

The two men met the following June. The 1974 ACM SIGFIDET workshop in Ann Arbor, Michigan put Bachman and Codd on the same session, each presenting for his own data model, followed by a panel discussion that everyone present understood to be a debate. It is conventionally treated as the moment the relational model stopped being the challenger; the ACM's fiftieth-anniversary retrospective starts its clock there. The same 1974 workshop is where Chamberlin and Boyce published SEQUEL.

Codd's own Turing Award came seven years after that, and his lecture — delivered at ACM '81 in Los Angeles on 9 November 1981, printed in CACM 25(2), February 1982 — answers Bachman without ever naming him. Its title is Relational Database: A Practical Foundation for Productivity, and its argument is that the navigational systems failed as productivity boosters for three reasons, of which the third is the killer: they "burdened application programmers with numerous concepts that were irrelevant to their data retrieval and manipulation tasks, forcing them to think and code at a needlessly low level of structural detail," and Codd's footnote names the CODASYL owner–member set as "the crux of the problem." The lecture then defines the property that a relational DBMS must have and Bachman's cannot:

> ...tabular systems, in which the programmer does his own navigation, and > relational systems, in which the system does the navigation for him, i.e., the > system provides automatic navigation.

Automatic navigation. Eight years after Bachman told the profession its future was to become skilled navigators, Codd took the same podium and said the navigation was going to be done by the machine. And then he went further, in section 6.2, and this is the sentence the whole of section 3 below turns on:

> The generation of access modules ... entails a quite sophisticated > optimization scheme which makes use of system-maintained statistics that would > not normally be within the programmer's knowledge. Thus, only on the simplest > of all transactions would it be possible for an average application programmer > to compete with this optimizer in generation of efficient code. Any attempts > to compete are bound to reduce the programmer's productivity.

Not "usually lose." Not "rarely worth it." Bound to. The human who tries to second-guess the planner is, by 1981 doctrine, making things worse by trying. That claim has now had forty-five years to be tested and section 3 gives it the grade it earned.

What actually shipped

The gap between the paper and the product is the most useful thing about this entry for a project that measures capability by what is deployed.

1970–1973: nothing. IBM had IMS, a successful hierarchical system with revenue attached, and no interest in a research paper that implied its replacement. Codd was at the San Jose research laboratory and did not work closely with the team that eventually built the prototype.

1973–1979: the prototype and the language. IBM began System R, and in 1974 Donald Chamberlin and Raymond Boyce published SEQUEL: A Structured English Query Language at the same SIGFIDET workshop where Codd and Bachman debated (pp. 249–264). SEQUEL was renamed SQL after a trademark conflict. Its design goal, in Chamberlin's own fiftieth-anniversary account, was the "walk-up-and-read" property: that a user with no specialized training could, in simple cases, understand what a query meant just by reading it. IBM's Phyllis Reisner tested the claim experimentally at San Jose State, showing that college students with no programming background reached reasonable proficiency after a few hours. This is an unusually well-evidenced design decision for 1974 — the usability claim was measured, not asserted.

1979: the first product, and not from IBM. Relational Software Inc. — later Oracle Corporation — shipped Oracle V2 in 1979 as the first commercially available SQL relational database. They numbered it 2 because nobody buys a version 1. IBM's own SQL/DS followed in 1981, and DB2 for MVS became generally available in April 1985. The company that funded the research was beaten to market by roughly six years by a company founded to commercialise the paper IBM had published.

1986–1987: the standard. ANSI adopted X3.135-1986, and ISO published a technically identical 9075 in 1987. One hundred and twenty pages, no explicit JOIN syntax, cross-join-and-filter only. Everything since is revision.

1985: the author disowns the products. In October 1985 Codd published a two-part article in Computerworld under the headline "Is Your DBMS Really Relational?", setting out twelve rules (numbered 0 to 12) as a test of the word. The occasion was vendors of hierarchical and network products appending "/R" to their names and declaring themselves relational. No system then or since satisfies all of them; SQL in particular permits duplicate rows and nulls, so an SQL table is not a relation and relational theory does not straightforwardly apply to it — the criticism Chris Date pressed for the rest of his career, to the point of arguing that SQL has no real right to the name. The inventor of the model spent the second half of his career grading the industry built on it and failing it. That is a fact worth holding next to any argument that commercial success validates a technical claim.

2009–2019: the detour that returned. The NoSQL wave abandoned the declarative interface for scale, then walked it back item by item: Google built Spanner and gave it SQL, drawing on the F1 experience; Amazon gave DynamoDB PartiQL; the document stores grew aggregation languages that converged on the same shape. The declarative interface was tested by defection and won, which is better evidence than never having been challenged.

Where it had got to by this reading, 19 August 2026

Codd was born on 19 August 1923 in Portland, Dorset — he would be 103 today. He interrupted mathematics and chemistry at Oxford to fly for the RAF, finished his degree in 1948, joined IBM in 1949, took a doctorate at the University of Michigan, moved to the San Jose research laboratory in 1967, and died on 18 April 2003 in Florida.

The March 2026 DB-Engines ranking has Oracle first, MySQL second, Microsoft SQL Server third and PostgreSQL fourth — four relational systems in the top four, with MongoDB fifth. Market estimates for relational database software cluster around $80bn a year and are not worth more precision than that, since the published figures disagree by 10% and none of them are audited. The interface is fifty-six years old, is the default in every stack, and its rival has no living defenders: nobody in 2026 proposes that application programmers should hand-code access paths, and Bachman's navigator is extinct as a job.

And the translator is still wrong. In August 2025, six authors including four of the original six revisited their 2015 study as Still Asking: How Good Are Query Optimizers, Really? (PVLDB 18(12), 5531–5536). Their findings, in their words: "Significant errors — often one order of magnitude or more for larger expressions — occur routinely across all systems." In PostgreSQL 9.4, "roughly 10% of the JOB queries failed to complete in any reasonable time frame due to cardinality estimation errors." The cost model, it turns out, "does not matter much"; the estimates do, and the estimates are bad. They quote Guy Lohman of IBM, writing in 2014 at the end of a long career in query optimization:

> The root of all evil, the Achilles Heel of query optimization, is the > estimation of the size of intermediate results, known as cardinalities. > Everything in cost estimation depends upon how many rows will be processed... > the cost model may introduce errors of at most 30% for a given cardinality, > but the cardinality model can quite easily introduce errors of many orders of > magnitude!

Ten years of machine learning aimed squarely at the problem has not fixed it either. The 2025 paper's summary of learned cardinality estimation and learned plan selection is that these methods improve estimates on benchmarks but carry "high training and inference costs, difficulty adapting to dynamic environments, challenges in obtaining high-quality training data, and unpredictability due to their black-box nature," and that "in real-world systems learned methods have not replaced classical query optimization yet." Microsoft's production experience with a learned approach is cited as limited gains and noisy measurement. The authors' own explanation for the industry's conservatism is a line any 2026 deployment engineer will recognise: "users rarely notice queries that become faster, but are quick to report regressions."

This is the state of the art of machine-chosen procedure, fifty-five years after the paper that demanded it, in the most favourable conditions that will ever exist: a closed formal input language, a fully specified schema, a deterministic execution engine, an unambiguous correctness criterion, decades of statistics, and the strongest commercial incentive in enterprise software. It works well enough to have eliminated its alternative, and it is still routinely off by orders of magnitude.

---

Why a reading would cite it

Three occasions, all live in the readings this project has already written, none of them requiring the reader to care about databases.

1. When a capability is claimed for "just tell it what you want," this is the control experiment. The Capabilities lens asks what is claimed against what is demonstrated. The declarative interface is the only case in computing history where the claim was made, the interface shipped, the rival died, and fifty-five years of measurement accumulated on the translator underneath — and the honest result is a split verdict that neither camp in 2026 quotes. The interface won totally. The translation stayed unreliable. Adoption did not converge on correctness; it converged on a workable division of labour in which the machine is usually right, humans have escape hatches, and everyone accepts a long tail of catastrophic plans as the cost of not writing access paths by hand. When a reading has in front of it a claim that agents can now be given goals rather than procedures, this entry supplies the base rate: the last time we did this, the interface was adopted universally within fifteen years and the underlying translation was still visibly broken at fifty-five. That is neither "it works" nor "it doesn't." It is a third answer, and it is the one with evidence behind it.

2. When a benchmark moves, this is the specific case where the benchmark and the ground truth can both be checked — and the ground truth failed. The natural-language-to-SQL problem is the direct descendant of Codd's 1974 casual user, and in 2026 it is one of the most heavily benchmarked capabilities in existence. The record as of this reading:

• Spider 2.0, the enterprise-grade benchmark introduced in 2024 (632 real-world tasks, databases with over 1,000 columns, multiple SQL dialects, solutions often exceeding 100 lines), was brutal on first contact: GPT-4o solved 10.1% of it, against 86.6% on the older Spider 1.0, and o1-preview managed 17.1%.
• By March 2026 the public Spider 2.0-Snow leaderboard is topped by a commercial agent claiming 96.70%, with a second at 96.53% and a third at 94.15%. The vendor's announcement states that the score "means we get there more often than anyone else" and offers no caveat about production applicability.
• On 19 January 2026, four researchers at the University of Illinois published an audit of the annotations those scores are computed against. Of the 121 Spider 2.0-Snow problems whose ground-truth SQL is public, they find an annotation error rate of 62.8%; BIRD Mini-Dev comes in at 52.8%, against a previously reported 32.3%. Re-scoring sixteen open-source agents on a corrected subset moves relative performance by −7% to +31% and leaderboard position by −9 to +9 places. One agent, CHESS, goes from 62% to 81% and from seventh to first. Rank correlation between the official leaderboard and the corrected one is 0.32 with p = 0.23 — statistically indistinguishable from no relationship.
• Meanwhile the honest current number on a fresh, verified benchmark is much lower. Spider 2.0-AIFunc (7 July 2026, 465 verified instances across 125 databases) reports the strongest proprietary models at 67–70% execution accuracy and the best open-source model at 58.1%, with errors concentrated in predicate specification and schema grounding.

A reading that needs to say "this benchmark number is not what it appears to be" can cite this entry for the fully worked instance: a leaderboard reading 96.7%, on a task whose published answer key is wrong 62.8% of the time, in the presence of an independently constructed benchmark on the same capability that reads 67%. It is also the cleanest available example of the difference between a capability that is verifiable in principle and a capability that is verified in practice — SQL is executable, results are comparable, the correctness criterion is objective, and the measurement still broke, because the humans writing the answer key misunderstood their own schemas.

3. When adoption figures are quoted, this is where the inflation happens and how to catch it. Uber published its own account of QueryGPT, its natural-language-to-SQL system, on 19 September 2024. What Uber itself claims: 1.2 million interactive queries a month across the platform, about 300 daily active users in a limited release, 78% of them saying the generated queries reduced the time they would have spent writing from scratch, and an authoring time falling from around ten minutes to about three. What Uber itself concedes, in the same post: "We do see instances where the LLM would generate a query with tables that don't exist or with columns that don't exist on those tables"; "It is impossible for the set of evaluation questions to fully cover the universe of business questions"; and "Running the same evaluation with no changes ... can result in different outcomes." The secondary retellings of that post now circulate figures Uber never published — 140,000 hours saved per month, $120m in annual productivity gains — derived by multiplying the seven-minute saving by the whole query volume rather than the 300-user pilot. The primary is modest and honest about its failure modes; the derivative is a headline. A reading under the Work and the economy lens, which ranks shipped deployments above surveys, can cite this entry for the shape of that specific distortion, with the primary and the derivative both named.

What this entry is not for. It is not evidence, it does not deposit, and it does not move the needle. It is also not a general-purpose "history repeats" card: the relational case is uncommonly favourable to the machine — closed schema, formal language, objective correctness — and citing it to imply that open-ended agent behaviour will follow the same course would be citing it against its own content. Section 4 says so at length.

---

What it got right, and what it got wrong

Nine dated claims, from three people, with the date made, the date due, and what actually happened. The two from Bachman are here because a claim is only gradeable against the alternative that was on offer at the time.

Claim 1 — Codd: "Future users of large data banks must be protected from having to know how the data is organized in the machine." Made September 1969 (submission), published June 1970. Due open-ended. Right, and more completely right than any other claim in this canon.

There is no serious counter-case. The number of working programmers in 2026 who specify physical access paths in application code is approximately zero outside of database internals and embedded systems. Bachman's navigator did not lose an argument; the occupation ceased to exist. The rival model's own descendants adopted the declarative interface voluntarily when they scaled past it and found they wanted it back.

The claim's strong form is what deserves attention, though — the second sentence, "A prompting service which supplies such information is not a satisfactory solution." That is the part still being relitigated. The 2026 answer to a model that does not understand a schema is, overwhelmingly, a prompting service: retrieval over table descriptions, curated workspaces of example queries, column-pruning agents, semantic layers. Uber's QueryGPT is literally an architecture of prompting services — an intent agent, a table agent, a column prune agent — assembled to tell the model how the data is organized. Codd's objection is not that this fails to help. It is that it reproduces the dependency: the system now works because someone maintains the description, and the description is a second thing that can drift from the representation it describes. That objection has not been answered by anyone in 2026; it has been outvoted.

Claim 2 — Codd: "responsibility for providing efficient response and throughput shifts from the individual user to the data system." Made 1970. Due when systems shipped, 1979 onward. Right about the shift; wrong by omission about what the shift would cost.

The shift happened exactly as described and for exactly the reason given — concurrency made per-user optimization incoherent. What the sentence does not contain, and what the exclamation mark after "efficient" hints he half knew, is that accepting responsibility is not the same as discharging it. The system took the job and has been performing it imperfectly ever since. Codd was right that the responsibility must move. He gave no estimate of how long it would take to move well, and the honest answer as of August 2025 is that it has not finished moving after fifty-five years.

This is the single most transferable line in the file. The argument for handing a decision to a machine is usually an argument that the human can no longer make it — not an argument that the machine will make it correctly. Both things were true in 1970 and both are true of agentic systems in 2026, and conflating them is the standard error in both eras.

Claim 3 — Bachman: the application programmer should "accept the challenge and opportunity of navigation within an n-dimensional data space," and the industry should "provide the programmer with effective tools for navigation." Made 28 August 1973, from the Turing Award podium. Due within a decade. Wrong on the outcome — and wrong in the way that matters most for 2026.

Within a decade the tools existed and nobody wanted them, because the machine had taken the task. Bachman was not wrong that navigation was hard, valuable, skilled work; he was wrong that it would remain human work. His error is not technical stubbornness — he understood the systems better than anyone alive — it is a category error about where a difficult task ends up when the difficulty comes from bookkeeping rather than judgment.

Grade this claim next to any 2026 argument that prompt engineering, context engineering, or model-steering is a durable skill. The structure is identical: a genuinely difficult competence, taught in earnest, with rules of the road and predicted anguish for those who resist. The one honest caveat on the analogy — and it cuts for the 2026 skeptic — is that Bachman's task was fully specifiable and Codd's replacement for it was formally defined, which is what made automation possible. Where the residual human task is judgment about what was meant, this claim's grade does not transfer. Section 4 develops that.

Two of Bachman's other 1973 numbers, for calibration on how well practitioners forecast their own field: he put the installed base at "between 1,000 and 2,000 true data base systems installed worldwide" and expected "tens of thousands" within ten years — an under-forecast by orders of magnitude on any modern counting. And he priced the database equipment to be installed in the 1980s at $100bn in 1970 dollars, warning that the absence of effective standardization could add 20 percent to the bill. He was arguing for standardization; the standardization that arrived was SQL, the standard for the model he was arguing against.

Claim 4 — Codd: "only on the simplest of all transactions would it be possible for an average application programmer to compete with this optimizer... Any attempts to compete are bound to reduce the programmer's productivity." Made 9 November 1981. Due continuously. Substantially right on the average case, and flatly wrong in the strong form he chose — which is the interesting half.

Every major relational system ships mechanisms whose entire purpose is to let a human override the optimizer: query hints, plan guides, plan pinning, forced join orders, statistics overrides. They exist because customers demanded them, and they are used, and using them is often correct. The 2025 restatement of the optimizer literature spends its "runtime approaches" section on techniques for recovering from the optimizer's own mistakes, and its "lessons" section explains that the industry resists even demonstrably better optimizers when they introduce regressions — because a plan that was fine and became catastrophic is a support ticket, and one that was always mediocre is not.

So: the average programmer cannot beat the optimizer on the average query, which is what Codd's evidence supported. The expert can beat it on the query that matters, which is what "bound to" denies. The failure mode of the strong claim is that it collapses a distribution into a rule. That is worth flagging in 2026 every single time someone says a model outperforms humans at a task: the claim is nearly always about the median case, the escape hatch nearly always gets built anyway, and the escape hatch is not evidence of failure — it is what a mature deployment of an imperfect automatic system looks like. Forty-five years of query hints is what "the machine usually decides better" looks like in production. Nobody should expect agentic systems to look tidier than that.

Claim 5 — Codd: the casual user will reach the data bank in English, through a system that conducts a dialogue to resolve ambiguity. Made 1974 ("Seven Steps to Rendezvous with the Casual User," IFIP Working Conference on Data Base Management, pp. 179–200; IBM RJ1333), prototyped 1978 (RENDEZVOUS Version 1, IBM RJ2144). Due, on the paper's own framing, "without a preliminary training period" — i.e. immediately. Arrived about fifty years late, in a form he specified correctly and for reasons he could not have specified.

Codd defined the casual user as someone whose interaction with a computer is so infrequent or unstructured that they will not learn a query language, and concluded that natural language or menu selection were the only viable routes. RENDEZVOUS was built to let such a user start from an imprecisely stated question and arrive, through an English dialogue with the system, at a precise query and an answer. It never became a product. Natural-language database interfaces were still being described by researchers in 2007 as "largely abandoned," with the note that had expectations been met they would by then be in wide use.

What is remarkable is how exactly the 1974 specification matches what shipped in 2023–2026. The clarifying dialogue — start from an imprecise question, converse, converge on an unambiguous query — is the interaction pattern of every conversational assistant now pointed at a database, and the leading enterprise systems are agentic exactly in Codd's sense: they ask, they explore the schema, they revise. He got the interface right in 1974 and was missing only the component that took half a century to build.

And the grade has to carry the size of the miss. Fifty years is not a detail; it is the finding. A correctly specified interface, from the inventor of the underlying model, at the company with the most resources in the industry, with a working prototype — and it took ten additional technology generations to become real. This is the best-documented case in the canon of specification being cheap and capability being the binding constraint, and it should be cited whenever a 2026 roadmap treats a well-specified capability as nearly delivered.

There is a self-grading wrinkle worth recording. Codd's own Turing Award lecture of 1981 — seven years after "Seven Steps," three after RENDEZVOUS — contains no discussion of natural language at all. Its productivity argument is entirely about SQL, QBE and application programmers; the "end user" it puts in "direct touch with the information" is a person using a formal query language at a terminal, not a person speaking English. The man who spent the mid-1970s on the casual user did not mention the casual-user-in-English project when given the profession's most prominent podium to summarise his work. That silence is the closest thing to a self-grade the record contains, and it is a quiet negative one.

Claim 6 — Chamberlin and Boyce: a structured English query language will serve "both the professional programmer and the more infrequent data base user," readable on sight by the untrained. Made 1974; the "walk-up-and-read" framing restated by Chamberlin in 2024. Due continuously. Half right, and the half that failed is the half being retried now.

The readability claim was tested and held: Reisner's San Jose State experiment showed non-programmers reaching proficiency in hours, and SELECT-FROM-WHERE remains one of the few pieces of technical syntax a layperson can read without instruction. The user claim failed. The infrequent data-base user did not learn SQL. The population that writes SQL is professional and always has been, which is precisely why the casual-user problem stayed open for Codd's successors and why text-to-SQL is a live commercial category in 2026. Fifty years of a language explicitly designed to be approachable did not produce approach.

This grades badly for a whole class of 2026 argument: that lowering the syntactic barrier to a capability broadens who uses it. SQL lowered the barrier about as far as a formal language can go and the user population did not move. What excludes the casual user is not syntax; it is knowing what the tables mean, which is the same thing that limits the models now — the Spider 2.0-AIFunc errors concentrate in schema grounding, not in SQL generation.

Claim 7 — Codd: relational systems can be extended to heterogeneous data — "images, text, and miscellaneous facts" — and "an affirmative answer is expected." Made 9 November 1981. Due open-ended. Right, after a fifteen-year detour that he did not predict and that nearly falsified it.

JSON columns, full-text indexes, array and geometry types, and vector columns for embeddings all landed inside relational systems, and the 2026 platforms have gone further than Codd's sentence: Snowflake, BigQuery and their peers expose model inference as native SQL functions, so that classification, extraction, sentiment and similarity search are expressions inside an ordinary query. The affirmative answer arrived. What Codd did not foresee was that between 2009 and 2019 a large part of the industry would conclude the answer was negative, leave for document and key-value stores, and then return. He was right on the question and had no model of the detour, which is a normal shape for a technologist's forecast: correct about the destination, blind to the fifteen years in which everyone drove somewhere else.

Claim 8 — Codd: no shipped DBMS is genuinely relational, and the word is being misapplied for marketing. Made October 1985, Computerworld, two parts, twelve rules. Due immediately. Right on the facts, comprehensively lost as an intervention, and the most useful entry in this file for anyone watching a word get diluted in 2026.

The technical content was correct and remains so: no system satisfies all twelve, SQL permits duplicate rows and nulls, and an SQL table with a null is not a relation. The intervention failed completely. "Relational" now means "has tables and speaks SQL," which is the vendors' definition, not Codd's, and the rules survive as a teaching artefact rather than a test anyone applies. The author of a term, at the peak of his authority, with a correct argument and a published checklist, could not stop an industry from using his word to mean what it found convenient.

That grade should be attached to every 2026 dispute over what "open," "agent," "reasoning," "frontier" or "safety-tested" means. The precedent is not encouraging and it is not ambiguous: definitional authority does not survive commercial adoption, even when the definer is right, even when he is the inventor, even when he publishes the test. Where the current canon's llama-weights-2023 records a word being stretched, this records the inventor's attempt to stop it and the attempt failing.

Claim 9 — the current one, entered here so it can be graded later. The 2026 claim under test is that natural-language-to-SQL is substantially solved at enterprise scale. Made continuously through 2026 by vendors on public leaderboards, most sharply on 1 March 2026 at 96.70% on Spider 2.0-Snow. Due: gradeable now on benchmarks, not before 2027 on deployments.

Recorded as of 19 August 2026, with no verdict placed: the top leaderboard score is 96.70% on a benchmark split whose public ground truth was found in January 2026 to be 62.8% erroneous; an independently constructed July 2026 benchmark on adjacent tasks puts the best proprietary models at 67–70%; the leaderboard's harder splits sit at 76.23% (Lite) and 65.6% (DBT); and the one large named production deployment with a published account reports user-satisfaction percentages rather than accuracy, and admits to hallucinated tables and non-reproducible evaluations. A future reading grading this claim should look for three things this entry deliberately does not have: an accuracy number from a deployment rather than a benchmark, an answer key someone audited before the scores were computed, and a failure rate for the queries that were executed and believed rather than the ones that were scored.

---

Commonly misused as

Not required for idea, but proposals.md attached a warning to this candidate in the owner's own words — that it worked "because the language was rigidly formal and the domain was closed, and the parts of the 1970s dream that needed natural language never arrived" — and a warning that specific deserves the section.

Misused as: proof that "just tell it what you want" works. The relational case is the most favourable possible instance of machine-chosen procedure and it is not a clean win. Every condition was in the machine's favour: the input was a formal language with a grammar, the schema was declared in advance and complete, the semantics of every operator were defined in relational algebra, correctness was objectively decidable by comparing result sets, the execution engine was deterministic, and fifty years of statistics accumulated on the same tables. Under those conditions the translator is still routinely off by orders of magnitude and still occasionally produces plans that never finish. Citing this entry as a precedent for goal-directed agents in open domains means citing the easy version of the problem as evidence about the hard one. If the reading wants that comparison, the honest form is: here is what it looks like when the conditions are perfect.

Misused as: proof that formalism was the obstacle and natural language is the prize. The record says the opposite and says it twice. SQL was designed to be readable by the untrained, was experimentally shown to be readable by the untrained, and the untrained still did not use it — so syntax was not the barrier. And the 2026 failures of natural-language querying concentrate in schema grounding and predicate specification, not in generating SQL — so the barrier is knowing what the data means, which natural language does not supply and never did. The formal half of Codd's programme is the half that works. The part that was never solved is the part where a human's imprecise intent has to be resolved against a particular organisation's particular vocabulary, and Codd identified that as the hard part in 1974 when he specified a dialogue rather than a translator.

Misused as: the reason text-to-SQL is trustworthy — "the output is executable, so it can be checked." The output being checkable is real and it is the strongest argument for this class of system. It is also, in practice, insufficient, and this entry contains the proof: executability guarantees that a query runs, not that it answers the question asked. A query joining the wrong tables executes perfectly and returns a number that is wrong, and no automatic check catches it, which is exactly how 62.8% of a benchmark's answer keys came to be wrong — they were written by SQL experts, they all executed, and they encoded misunderstandings of the schema. Verifiability is a property of the artefact, not of the intent behind it. Anyone arguing that formal, executable output makes a model's work self-checking should be shown the annotation audit.

Misused as: a lone-genius-versus-hidebound-incumbent story. It is the most popular telling and it is bad history that produces bad inferences. Codd credits C. T. Davies of IBM Poughkeepsie with convincing him the problem mattered, and thanks four colleagues; his 1981 lecture thanks the System R team, the QBE team at Yorktown, the PRTV team in England, Chris Date and Sharon Weinberg. The opponent was a Turing Award laureate arguing a coherent position from the podium. IBM's reluctance was not stupidity, it was an installed base with revenue attached — and IBM funded the research, published the paper, and built the prototype and the language, then got beaten to market by a startup founded to commercialise its own published work. The transferable lesson is about the distance between publishing an idea and capturing it, which is a live question under the Concentration lens every time a lab publishes.

Misused as: evidence that a shipped, dominant technology has been validated. Its inventor spent 1985 publishing a twelve-point test that no shipped implementation passed, and lost. Dominance and correctness came apart here in full public view, with the person best qualified to referee saying so in print.

---

Sources

Read directly, at source. Four primaries are image-encoded PDFs; each was fetched and read page by page as rendered images, and every quotation attributed to them below is from the document, not from a secondary account of it.

• **E. F. Codd, "A Relational Model of Data for Large Shared Data Banks," Communications of the ACM 13(6), June 1970, pp. 377–387, read via the University of Pennsylvania mirror (engineering.upenn.edu/~zives/03f/cis550/). All eleven pages read. Source for: the abstract including "A prompting service which supplies such information is not a satisfactory solution"; the three dependencies of §1.2 and the "It is unnecessary to single out any system" sentence; the five-structure failure argument on p. 378; §1.3's relational view; §1.4 normalization and the "devoid of pointers" list; §1.5's universal data sublanguage and "The universality of the data sublanguage lies in its descriptive ability (not its computing ability)"; §1.6's "corresponding — and efficient! — actions" passage** and the shift-of-responsibility sentence; §2's operators, the connection trap and the two redundancies; §2.3's consistency definition; the acknowledgment to C. T. Davies; "Received September, 1969; revised February, 1970"; and the complete ten-item reference list including the Feldman and Rovner Stanford AI report.
• **E. F. Codd, "Relational Database: A Practical Foundation for Productivity," the 1981 ACM Turing Award Lecture, delivered 9 November 1981 at ACM '81, Los Angeles; CACM 25(2), February 1982, pp. 109–117**, read via the mirror at dcs.gla.ac.uk/~wpc/grcs/a1981-codd.pdf. All nine pages read. Source for: the productivity-crisis opening; the three reasons DBMS failed as productivity boosters and the CODASYL owner–member footnote; the automatic-navigation definition in §4; the cursor passage in §5 ("the programmer is not engaging in navigation"); the "Any attempts to compete are bound to reduce the programmer's productivity" passage in §6.2; §7's heterogeneous-data expectation; the acknowledgments; and the negative finding that the lecture contains no discussion of natural language.
• **C. W. Bachman, "The Programmer as Navigator," the 1973 ACM Turing Award Lecture, delivered 28 August 1973 at the ACM Annual Conference, Atlanta; CACM 16(11), November 1973, pp. 653–658**, read via people.csail.mit.edu/tdanford/6830papers/. Source for: the Copernicus opening; the award citation read by Richard G. Canning; the "radically new point of view ... navigator within a database" passage and the "rules of the road"; the anguish sentence; the closing proposition; the 1,000–2,000 installed systems and "tens of thousands" forecast; the $100bn 1980s equipment estimate and the 20% standardization figure; and the Weyerhaeuser I-D-S deadlock statistics.
• V. Leis, A. Gubichev, A. Mirchev, P. Boncz, A. Kemper, T. Neumann, "Still Asking: How Good Are Query Optimizers, Really?", PVLDB 18(12), 2025, pp. 5531–5536, read at vldb.org/pvldb/vol18/. Source for: the Guy Lohman 2014 "Achilles Heel" quotation; "Significant errors — often one order of magnitude or more for larger expressions — occur routinely across all systems"; the PostgreSQL 9.4 10%-of-JOB-queries finding; "the cost model does not matter much"; the assessment that learned methods "have yet to see widespread adoption in industry"; and the regressions-versus-improvements observation. The 2015 original it revisits is PVLDB 9(3), pp. 204–215.
• T. Jin, Y. Choi, Y. Zhu, D. Kang, "Pervasive Annotation Errors Break Text-to-SQL Benchmarks and Leaderboards," arXiv:2601.08778v3, 19 January 2026, University of Illinois Urbana-Champaign, read at arxiv.org. Source for: the 62.8% Spider 2.0-Snow and 52.8% BIRD Mini-Dev annotation error rates; the 121-problem public ground-truth subset; the −7% to +31% performance and −9 to +9 rank changes across sixteen re-evaluated agents; the CHESS 62%→81% and 7th→1st example; and the Spearman correlations (0.85 on the original subset, 0.32 with p = 0.23 on the corrected one).

Fetched and read as page text or abstract, one remove from the rendered document:

• spider2-sql.github.io, the Spider 2.0 leaderboard, fetched 19 August 2026 — the Snow, Lite and DBT tables and the benchmark's stated characteristics (632 tasks, >1,000 columns, multiple dialects, solutions often over 100 lines), and the original GPT-4o 10.1% / 86.6% and o1-preview 17.1% figures. The page carries submitted results; the entry above treats the top scores as vendor claims rather than independent measurements, which is what they are.
• genloop.ai/blogs/genloop-is-1-on-spider-2.0, dated 1 March 2026 — the 96.70% claim and the "we get there more often than anyone else" framing, with no stated methodology and no production caveat.
• T. Liu, C. Xu, F. Lei, N. L. Kuang, J. Chen, T. Yu, J. McAuley, Z. Yao, Y. He, "Spider 2.0-AIFunc: Extending Real-World Text-to-SQL to AI-Native SQL Workflows," arXiv:2607.06229, 7 July 2026 — abstract read in full: 465 verified instances, 125 databases, six AI function types on Snowflake, 67–70% for the strongest proprietary models and 58.1% for the best open-source, errors concentrated in predicate specification, schema grounding and AI function parameterization.
• uber.com/blog/query-gpt/, 19 September 2024 — the 1.2m monthly queries, ~300 daily active users, 78% time-saving response, ten-minutes-to-three claim, the evaluation metrics used, and the three admissions quoted in section 2.

Verified through search summaries and secondary sources, named because specific claims rest on them and no primary was reachable in this run:

• D. D. Chamberlin and R. F. Boyce, "SEQUEL: A Structured English Query Language," Proc. 1974 ACM SIGFIDET Workshop, Ann Arbor, pp. 249–264 — the design intent for "both the professional programmer and the more infrequent data base user," and Phyllis Reisner's San Jose State experiment. The "walk-up-and-read" phrasing and the null/duplicate/orthogonality controversies are from **D. Chamberlin, "50 Years of Queries," CACM 67 (2024), pp. 110–121**, whose full text returned HTTP 403 to this run; it is quoted here only at second hand and a future session with access should check the paraphrases in claim 6.
• E. F. Codd, "Seven Steps to Rendezvous with the Casual User," IFIP Working Conference on Data Base Management, 1974, pp. 179–200 (IBM RJ1333), and "Rendezvous Version 1: An Experimental English-Language Query Formulation System for Casual Users of Relational Data Bases," IBM RJ2144, 1978 — the definition of the casual user and the dialogue-to-precise-query design. The 2007 assessment that natural-language interfaces to databases remained "largely abandoned" is from M. Minock et al., "A STEP Towards Realizing Codd's Vision of Rendezvous with the Casual User," VLDB 2007 demo paper.
• **E. F. Codd, "Is Your DBMS Really Relational?", Computerworld, October 1985**, two parts, twelve rules numbered 0–12 — the occasion (vendors appending "/R"), the fact that no system satisfies all twelve, and C. J. Date's position that SQL's departures disqualify it from the name.
• The 1974 SIGFIDET workshop debate between Codd and Bachman in Ann Arbor, June 1974 — the format (two prepared talks, then a panel everyone treated as a debate) and its standing as the point from which the relational era is conventionally dated.
• Product chronology — Oracle V2 in 1979 as the first commercially available SQL relational system, IBM SQL/DS in 1981, DB2 for MVS generally available April 1985; ANSI X3.135-1986 and the technically identical ISO 9075-1987, 120 pages, no explicit JOIN syntax.
• Biography — born 19 August 1923 in Portland, Dorset; RAF pilot; Oxford mathematics 1948; IBM from 1949; doctorate at the University of Michigan; IBM San Jose from 1967; died 18 April 2003. Britannica and the ACM laureate record agree on these; the ACM page itself returned HTTP 403 to this run.
• DB-Engines ranking, March 2026 — Oracle, MySQL, Microsoft SQL Server and PostgreSQL in the top four, MongoDB fifth. The live ranking page failed TLS verification in this run, so this is the March figure from search summaries rather than the current month's; a later session should refresh it. Market size for relational database software is given in the text as "around $80bn a year" and deliberately not more precisely: the published estimates disagree by more than 10% and none of them are audited.
• The NoSQL return — Spanner acquiring SQL semantics via the F1 experience, DynamoDB acquiring PartiQL, and the general convergence of document stores on declarative query languages.

Not obtained. The Selinger et al. 1979 System R optimizer paper ("Access Path Selection in a Relational Database Management System," SIGMOD 1979, pp. 23–34) is cited in Codd's Turing lecture as reference [27] and is the actual implementation of the shift described in claim 2; it was not fetched in this run and everything said here about the optimizer's behaviour comes from the 2015 and 2025 Leis papers instead. The Computerworld originals of the twelve rules were not located in full text. No primary was found in which Codd graded the natural-language project himself; the 1981 lecture's silence is the strongest available evidence and it is inference, marked as such in claim 5.