What Is RDBMS? The Relational Model, ACID, and Why It Keeps Winning

---

A relational database management system (RDBMS) stores data as tables of rows and columns, enforces the relationships between them with keys, and exposes all of it through SQL. E. F. Codd defined the model in 1970 to solve one problem: applications should not have to know how their data is stored. Fifty-six years later, PostgreSQL alone reaches 55.6% of developers.

---

Object databases, XML databases, document stores, key-value stores and the graph wave were each launched as the successor to the relational model. Every one found a niche or grew a SQL interface instead. So the useful question is not what an RDBMS is, which takes a paragraph, but why nothing displaced it. The answer is in the primary literature.

• The sentence in Codd’s 1970 paper that explains why the model exists
• What ACID guarantees, and why “ACID compliant” is not serializable
• Whether Codd’s rules are twelve or thirteen, and what the model costs you

Quick facts
What it is	A DBMS that stores data as relations: tables of rows and columns, with relationships enforced by the engine
Originated	E. F. Codd, IBM Research, 1970 (Communications of the ACM 13(6), pp. 377-387)
Query language	SQL, standardized as ISO/IEC 9075; ninth edition SQL:2023
Core guarantee	ACID transactions (Härder and Reuter, 1983)
Core discipline	Normalization, 1NF through 5NF
Current adoption	Four of the five most-used databases (Stack Overflow 2025, n=26,083)

---

What is a relational database management system?

Permalink to “What is a relational database management system?” #

An RDBMS is a database management system that implements Codd’s relational model and exposes it through SQL. Data lives in relations, which almost everyone calls tables: rows are records, columns are attributes, and relationships between tables are declared as keys the engine enforces rather than trusting application code to remember.

The definition is easy. The reason the model exists is the useful part, and it is the first line of the paper that started it. According to E. F. Codd of IBM Research (1970), writing in Communications of the ACM 13(6), pp. 377-387: “Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation).”

That is the data-independence thesis, and it answered a specific pain: applications reached into storage structures directly, so changing a file layout broke every program that read it. Codd put a logical model in between, and that decision is what people actually like: data modeling finishes before you pick an engine, database schema examples stay portable, and a planner can rewrite your query because you never told it how to run.

The category, the member and the language then get mixed up constantly.

Question it settles	DBMS	RDBMS	SQL
What is it?	Any software that manages a database	A DBMS that implements the relational model	A language, standardized as ISO/IEC 9075
Which contains which?	The superset	A subset, not a better product	Neither. It is how you address either
How is data organized?	However its model does: relational, document, key-value, hierarchical or graph	As relations: tables of rows and columns with declared keys	Nothing. It queries what the system holds
Where do relationships live?	Wherever the model puts them, sometimes only in application code	In the schema, as keys the engine enforces	Declared in DDL, traversed with JOIN
Does it guarantee ACID?	Depends on the system	Standard in every mainstream relational engine	Defines transaction syntax; the engine supplies the guarantee

Read the rest of this page as a set of design decisions with consequences, not as a glossary.

---

How does an RDBMS actually work?

Permalink to “How does an RDBMS actually work?” #

Four mechanisms do the work between a SQL string arriving and rows coming back: the relation, keys, the declarative query and the system catalog.

Tables, rows, and what “relation” actually means

Permalink to “Tables, rows, and what “relation” actually means” #

A relation is a set of tuples drawn from defined domains. Two things follow from the word “set”. Order is not part of the data, so a query without ORDER BY has no guaranteed row order whatever your last hundred runs looked like. And duplicates are not free, which is why every serious table has a key.

The mathematics is not decoration. Filter a relation and you get a relation; join two and you get a relation. Because operations compose, an engine can rewrite a chain of them into a different chain that provably returns the same rows.

Keys: what primary and foreign keys actually enforce

Permalink to “Keys: what primary and foreign keys actually enforce” #

A primary key is identity. One value, one row, never null. A foreign key is referential integrity: a value in this column must exist as a key in another table, and the engine refuses any write that breaks that.

The question that matters is who enforces it. Validation in application code is a promise that every writer remembers to check. A foreign key is the database refusing to hold an invalid state whatever is talking to it, including the migration script someone ran at 2am. That is categorically stronger than data integrity rules living in a service layer.

Declarative queries and the query planner

Permalink to “Declarative queries and the query planner” #

SQL states what you want, not how to get it. The planner picks the index, the join order and the join algorithm from statistics about the data as it stands. So the same query survives a new index, a partitioned table or bigger hardware: the plan is recomputed, the statement is not.

The system catalog

Permalink to “The system catalog” #

The database describes itself in tables you query with the same SQL you use on your data. INFORMATION_SCHEMA and its per-engine equivalents hold every table, column, type, constraint and privilege. That is how a tool discovers a schema without being told about it, and why you can query INFORMATION_SCHEMA on Snowflake to enumerate an estate you have never seen.

Codd required this: his fourth rule says the catalog must itself be relational and queryable in the same language as the data. It is also where the model’s generosity stops. The catalog records that a column is VARCHAR(2) and not null, never what the two characters mean.

---

What does ACID actually guarantee?

Permalink to “What does ACID actually guarantee?” #

ACID names four guarantees a transaction makes when concurrent work meets a crash. They are properties of the transaction, not promises about your business rules, and one of them is routinely over-read.

The acronym has an origin, and it is not the one usually cited. According to Theo Härder and Andreas Reuter (1983), in ACM Computing Surveys 15(4), pp. 287-317, the four properties are named together as ACID for the first time.

The properties themselves are older. Jim Gray (1981) set out atomicity, consistency and durability at VLDB as what makes a transaction a transaction; Härder and Reuter named the set and folded isolation into it. Crediting Gray with the acronym, as most pages do, gets the history exactly one paper wrong.

Their consistency is narrower than the folk version: a database is consistent if and only if it contains the results of successful transactions. That is a claim about which writes survived. It says nothing about whether your invariants hold.

Property	What it guarantees	What it does not	Common misreading
Atomicity	Every write takes effect, or none does	What other transactions see mid-flight	That atomic also means invisible
Consistency	The results of successful transactions, plus declared constraints	That your business rules are right, or undeclared ones checked	That the C covers application invariants
Isolation	Transactions kept apart as far as the configured level requires	An outcome equal to running them one at a time, unless serializable	That any ACID system is serializable
Durability	Once a commit returns, those writes survive a crash	A lost volume, a lost region or a bad backup policy	That durability is a disaster-recovery plan

Why “ACID compliant” does not mean serializable

Permalink to “Why “ACID compliant” does not mean serializable” #

The isolation letter is the one that gets over-read, and the paper showing why is thirty years old. According to Berenson, Bernstein, Gray, Melton, O’Neil and O’Neil (1995), in A Critique of ANSI SQL Isolation Levels at ACM SIGMOD, the SQL-92 levels fail to characterize the isolation levels real systems implement.

SQL-92 defines its levels by three anomalies they forbid: dirty reads, non-repeatable reads and phantoms. That vocabulary is not sufficient, so the paper introduces snapshot isolation as a distinct multiversion type the ANSI levels cannot describe.

Write skew makes it concrete. Two doctors are on call, a rule says at least one must stay, each reads a snapshot showing the other on call, and each takes themselves off. Both commits succeed, each valid against its own snapshot.

The rule is now broken and the database never noticed. That is the whole argument: no dirty read, no non-repeatable read and no phantom occurred, so the three anomalies the ANSI levels are defined by cannot describe what went wrong. Snapshot isolation forbids all three and still permits this.

Most production engines default to read committed or snapshot isolation, both weaker than serializable. So the question worth asking of a system is not whether it is ACID but which isolation level it runs at by default.

---

Normalization: 1NF through 5NF, and when to stop

Permalink to “Normalization: 1NF through 5NF, and when to stop” #

Normalization runs as a sequence of forms, each removing one class of redundancy, and each arrived in a specific paper rather than in folklore. A form is violated when an attribute depends on something other than the whole key, and satisfied when you decompose the relation.

Normal form	What it eliminates	Dependency type	Introduced
1NF	Non-atomic values and repeating groups in a column	None (atomicity)	Codd, CACM, 1970; named in RJ909, 1971
2NF	Attributes depending on only part of a composite key	Functional	Codd, IBM RJ909, 1971
3NF	Attributes depending on other non-key attributes	Functional, transitive	Codd, IBM RJ909, 1971
BCNF	Anomalies 3NF leaves when a non-key attribute determines part of a key	Functional	Boyce and Codd, 1974
4NF	Independent multivalued facts crammed into one relation	Multivalued	Fagin, ACM TODS, 1977
5NF	Redundancy removable only by decomposing into three or more relations	Join	Fagin, 1979

The jump at 4NF is where the theory stops being about single-valued facts. A course determines a set of instructors and, independently, a set of textbooks; storing both in one relation forces a fake pairing between them. According to Ronald Fagin (1977), in Multivalued Dependencies and a New Normal Form for Relational Databases, ACM Transactions on Database Systems, every relation schema decomposes into 4NF without losing information.

Normalization optimizes for correctness, not speed. Removing redundancy removes the possibility of two rows disagreeing, and it costs you joins at read time. That trade is why real systems run both disciplines at once: 3NF or BCNF in the transactional layer, and a deliberately denormalized analytical layer of star and snowflake schemas, materialized views and precomputed aggregates.

That split is settled practice rather than a finding from one paper, and it is why data modeling concepts diverge between a data warehouse and a database, a data lake and a data warehouse, and a pattern like data vault architecture. So “how far should I normalize” has no numeric answer. Normalize until redundancy that could produce a contradiction is gone, then denormalize on purpose, in a separate layer, with the reason written down.

---

Are Codd’s rules twelve or thirteen?

Permalink to “Are Codd’s rules twelve or thirteen?” #

Thirteen. They are numbered 0 through 12, and the “12 rules of RDBMS” in every textbook summary is a miscount produced by starting at one. Codd published them as two Computerworld articles in October 1985, “Is your DBMS really relational?” and “Does your DBMS run by the rules?”, written as a test vendors were failing while calling their products relational.

Rule 0 is the one that goes missing. The Foundation Rule: a system claiming to be relational must manage its databases entirely through relational capabilities. Drop it and the list reads as twelve technical requirements. Keep it and the list has a thesis: partial relational support is not relational.

Rule	What it requires
0. Foundation	Manage databases entirely through relational capabilities
1. Information	All information represented explicitly as values in tables
2. Guaranteed access	Every datum reachable by table name, primary key value and column name
3. Systematic null treatment	Nulls handled uniformly for missing or inapplicable data, whatever the type
4. Active online catalog	The catalog is relational and queryable in the same language as the data
5. Comprehensive data sublanguage	One language for definition, manipulation, constraints, transactions and authorization
6. View updating	Every theoretically updatable view is updatable by the system
7. Set-level insert, update, delete	Operations work on sets of rows, not one row at a time
8. Physical data independence	Applications survive changes to storage and access methods
9. Logical data independence	Applications survive information-preserving changes to base tables
10. Integrity independence	Constraints live in the catalog, not in application code
11. Distribution independence	Applications keep working when data is distributed
12. Nonsubversion	No low-level interface can bypass the relational integrity rules

No commercial system satisfies all thirteen, and none ever has. Rule 6 alone defeats every engine on the market. That was the point: Codd wrote a standard nobody met so buyers could see how far short a product fell.

---

Is SQL still used in 2026?

Permalink to “Is SQL still used in 2026?” #

Yes, and the margin is not close. According to the Stack Overflow Developer Survey 2025, which asked 26,083 respondents which databases they had used for extensive development work in the past year, PostgreSQL leads at 55.6%, then MySQL 40.5%, SQLite 37.5% and Microsoft SQL Server 30.1%.

MongoDB, the highest-placed non-relational system in that survey, reaches 24.0%. Four of the top five are relational, and among the 21,126 professional developers PostgreSQL rises to 58.2%.

Engine	License model	Typical fit	2025 developer usage
PostgreSQL	Open source (PostgreSQL License)	General-purpose OLTP; extensions for JSON, geospatial, vector	55.6%
MySQL	Open source (GPL), commercial editions	Web applications and read-heavy workloads	40.5%
SQLite	Public domain	Embedded and on-device storage, single writer	37.5%
Microsoft SQL Server	Commercial	Transactional and reporting in a Microsoft estate	30.1%
Oracle Database	Commercial	High-end OLTP, strict availability requirements	Not in the top five
MariaDB	Open source (GPL)	MySQL-compatible, community-governed	Not in the top five

The standard has not been standing still either. SQL:2023 is ISO/IEC 9075:2023, the ninth edition, adopted June 2023. ISO/IEC 9075-16:2023 adds Part 16, Property Graph Queries, so tables can be queried as a property graph without leaving SQL. And per Peter Eisentraut (2023), a PostgreSQL core committer, it adds a native JSON data type.

Read those together and the trend runs opposite to the usual one: the standard absorbed the graph and document challengers instead of losing to them. According to Michael Stonebraker of the Massachusetts Institute of Technology, a Turing Award laureate in 2014, and Andrew Pavlo of Carnegie Mellon University, writing in SIGMOD Record 53(2), June 2024:

“We contend that most systems that deviated from SQL or the RM have not dominated the DBMS landscape and often only serve niche markets. Many systems that started out rejecting the RM with much fanfare (think NoSQL) now expose a SQL-like interface for RM databases.”

The relational-versus-NoSQL argument is not re-run here; three pages carry it in full: relational database vs NoSQL, non-relational database vs relational and relational vs document database. What the standard’s own history supplies is the defensible version of “the relational model won”: not that the alternatives failed, but that the successful ones converged on the interface they set out to replace.

---

What are the real tradeoffs of the relational model?

Permalink to “What are the real tradeoffs of the relational model?” #

The relational model has real costs, and they are not the ones the “relational databases don’t scale” line points at. Four are worth naming precisely, because vague versions have driven expensive migrations.

Adding a NOT NULL column to a large live table is a rewrite, a lock, or a multi-step migration with a backfill, and that cost follows from the guarantee: an engine that refuses invalid states has to check every existing row first. Normalization pushes work to read time, so past a point the planner’s choices, index coverage and lock contention become your capacity ceiling rather than hardware. PostgreSQL’s process-per-connection model makes pooling mandatory at volume, and its write amplification is the known cost of the same multiversion machinery that gives you snapshot reads. Genuinely schemaless data, forced into a relation, produces either a column of JSON or a table with ninety nullable columns.

Practitioners argue this in public, and the argument is more useful than the meme. The Hacker News threads behind “just use Postgres” (2024, 2026) run both ways: alongside the enthusiasm sits the criticism that a decades-old codebase is a poor foundation for iterating quickly on newer paradigms, and the sharper framing that a relational database is one form of persistent storage, “not application frameworks nor scalable messaging systems by design.”

If distributed SQL enters the conversation, skip the CAP shorthand. According to Eric Brewer (2012) in CAP Twelve Years Later, IEEE Computer 45(2), “two out of three” is misleading: you trade consistency against availability only during a partition.

Three mistakes account for most of the damage.

1. Treating normalization as performance tuning. It is a correctness discipline. Normalizing to speed up reads is backwards, and denormalizing for correctness is incoherent.
2. Reading “ACID compliant” as serializable. Most engines default to something weaker, so a system can be fully ACID compliant while letting two transactions break a rule neither could see.
3. Assuming the schema documents itself. A VARCHAR(2) column named acct_st_cd is a valid relational attribute and it means nothing to anyone who was not in the room. That is why teams maintain a data dictionary alongside the database, and why a data dictionary and a data catalog solve different halves of the same gap.

---

---

What a relational schema does not tell you

Permalink to “What a relational schema does not tell you” #

Codd’s separation of the logical model from physical storage was a deliberate act of hiding, and it worked so well that it defines the category. What the model never promised to carry was meaning: nothing in the definition of a relation requires a column to say what it is for. acct_st_cd VARCHAR(2) NOT NULL is a complete and correct relational attribute. For fifty-six years, a person supplied the rest.

That gap became measurable the moment the reader stopped always being a person. According to Lei, Chen, Ye, Cao and colleagues (2024) in Spider 2.0, an Oral at ICLR 2025, the best agent framework tested solves 21.3% of 632 real enterprise text-to-SQL problems, against 91.2% on the original Spider benchmark and 73.0% on BIRD. The databases are the difference: real ones, on BigQuery and Snowflake, “often containing over 1,000 columns.” Solving them, the authors write, “frequently requires understanding and searching through database metadata, dialect documentation, and even project-level codebases.” An independent benchmark produced that number. What it measures is the cost of what the relational model deliberately left out.

The recovery is measurable too. Atlan’s AI Labs ran 174 unique queries and 522 evaluations against a 13-table, 94-column dataset and found that enhanced metadata improves query accuracy: the query win rate moved from 16.1% to 22.2%, a 38% relative improvement at p < 0.0001.

Both halves matter. A win rate of 22.2% is still mostly wrong, and the model never changed; only the context arriving with the schema did. Column descriptions, glossary terms and column-level lineage are the material a CREATE TABLE statement was never designed to hold, and a context layer is where that gets maintained as a first-class asset instead of a wiki page nobody updates.

None of which changes what an RDBMS is. It changes who is reading it. If something is about to query your schemas and cannot ask a colleague what acct_st_cd means, the open question is how much your metadata says about those columns, because that is the distance between a correct schema and AI-ready data. Whether you close it is a separate decision from whether the model was right, and the model was right.

---

FAQs about RDBMS

Permalink to “FAQs about RDBMS” #

1. What is a relational data management system?

Permalink to “1. What is a relational data management system?” #

The same thing as a relational database management system: software that stores data in tables of rows and columns, enforces the relationships between them with primary and foreign keys, and lets you query it with SQL. The shorter phrase just drops “database”; RDBMS is the standard abbreviation.

2. What is the difference between DBMS and RDBMS?

Permalink to “2. What is the difference between DBMS and RDBMS?” #

A DBMS is the category; an RDBMS is a member of it. Any system that stores and manages a database is a DBMS, whatever its data model. An RDBMS is the subset implementing the relational model: relations, keys the engine enforces, SQL as the interface. Superset and subset, not worse and better.

3. Is SQL a relational database management system?

Permalink to “3. Is SQL a relational database management system?” #

No. SQL is a language, standardized as ISO/IEC 9075; an RDBMS is software that implements it. You use SQL to define tables, query them, change data and control transactions. Storage, planning, concurrency control and durability are the system’s job, not the language’s.

4. What are 1NF, 2NF, and 3NF?

Permalink to “4. What are 1NF, 2NF, and 3NF?” #

The first three normal forms, each removing one class of redundancy. 1NF requires atomic values, no repeating groups inside a column. 2NF removes attributes depending on only part of a composite key. 3NF removes attributes depending on other non-key attributes. Codd formalized 2NF and 3NF in IBM Research Report RJ909, 1971.

5. What are the 12 rules of RDBMS?

Permalink to “5. What are the 12 rules of RDBMS?” #

Thirteen, not twelve. Codd published them in Computerworld in October 1985, numbered 0 through 12, with Rule 0 the Foundation Rule: a system must manage its databases entirely through relational capabilities. The “12 rules” count comes from dropping Rule 0, and no commercial system satisfies all thirteen anyway.

6. What are the five main components of a relational database?

Permalink to “6. What are the five main components of a relational database?” #

Most treatments name the relation, the attribute with its domain, the tuple, the keys and the constraints. A working RDBMS adds what makes those usable: a SQL engine and query planner, transaction and concurrency control, a storage layer, and a system catalog. No standards body defines a list of five.

7. What are the 7 types of DBMS?

Permalink to “7. What are the 7 types of DBMS?” #

There is no standard seven. The number circulates because reference sites group systems by data model and land on roughly this set: relational, document, key-value, wide-column, graph, hierarchical and network. Real systems often implement several at once, so treat any fixed count as a teaching device.

8. Is Excel a relational database management system?

Permalink to “8. Is Excel a relational database management system?” #

No. A spreadsheet holds tabular data and can fake a join with a lookup formula, but it enforces nothing: no primary keys, no referential integrity between sheets, no declared column types, no transactions, no isolation between editors. It stores a layout; an RDBMS stores a model and defends it.

9. What are the disadvantages of relational databases?

Permalink to “9. What are the disadvantages of relational databases?” #

The real costs are schema change on a large live table, join and lock cost under high concurrency, a poor fit for genuinely schemaless data, and per-engine limits such as PostgreSQL’s process-per-connection model. Horizontal write scaling is harder than in systems built around partitioning. The model records structure, not meaning, so documentation stays a separate job.

---

Sources

Permalink to “Sources” #

1. A Relational Model of Data for Large Shared Data Banks, Communications of the ACM 13(6), 1970
2. Principles of Transaction-Oriented Database Recovery, ACM Computing Surveys 15(4), 1983
3. The Transaction Concept: Virtues and Limitations, VLDB, 1981
4. A Critique of ANSI SQL Isolation Levels, ACM SIGMOD, 1995
5. Multivalued Dependencies and a New Normal Form for Relational Databases, ACM TODS, 1977
6. What Goes Around Comes Around… And Around…, SIGMOD Record 53(2), 2024
7. Developer Survey 2025: Technology, Stack Overflow
8. SQL:2023 is finished: Here is what’s new, Peter Eisentraut
9. ISO/IEC 9075-16:2023, Property Graph Queries (SQL/PGQ), ISO
10. CAP Twelve Years Later: How the “Rules” Have Changed, IEEE Computer 45(2), 2012
11. Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows, arXiv 2411.07763
12. Postgres is eating the database world, Hacker News
13. It’s 2026, Just Use Postgres, Hacker News