What Is an RDBMS?

An RDBMS is a database engine that stores data in relations — tables of rows with named columns — and manages them on your behalf. MySQL, PostgreSQL, Oracle, SQL Server and SQLite are all RDBMS products. The word relational points at Codd's model, where the significant guarantees are structural rather than physical.

CREATE TABLE account_balances (
  account_id INTEGER PRIMARY KEY,
  owner TEXT NOT NULL,
  balance_cents INTEGER NOT NULL
);

INSERT INTO account_balances (account_id, owner, balance_cents) VALUES
  (1, 'Ada Lovelace', 5000),
  (2, 'Grace Hopper', 2000);

-- Move money atomically: both rows change, or neither does.
BEGIN;
UPDATE account_balances SET balance_cents = balance_cents - 1500 WHERE account_id = 1;
UPDATE account_balances SET balance_cents = balance_cents + 1500 WHERE account_id = 2;
COMMIT;

SELECT account_id, owner, balance_cents FROM account_balances ORDER BY account_id;

The guarantee is that the engine, not your application, keeps the data consistent. Four things follow from the relational model. Rows are addressable by a key, so a foreign key can point at exactly one row. Relationships are expressed as set operations — joins — evaluated by an optimizer that can pick an index. Constraints are enforced by the engine at write time, so an invalid row cannot exist even if a buggy service tries to write it. And a transaction groups several writes into one indivisible unit, as the transfer above shows: at every instant, the total of both balances is 7000 cents.

Compare that with a JSON file or an in-memory dictionary. There, uniqueness, referential integrity and atomicity are properties of whatever code you wrote, and every additional service that touches the file has to re-implement them. The engine owning correctness is the reason the relational model survived forty years of alternatives.

The caveat is that RDBMS guarantees are only as good as the constraints you actually declare. A table with no foreign keys gets no referential integrity, no matter how good the engine is.

ACID is the informal name for the four properties that make a transaction safe to rely on, and each letter maps onto something concrete your code depends on.

Atomicity means all-or-nothing. If a transaction that transfers money updates two rows and the second update fails, the first is undone — no half-finished transfer survives. This is what lets you write multi-step changes without defensive cleanup code.

Consistency means the database moves from one valid state to another valid state, never to an invalid one. The engine enforces this through declared constraints: foreign keys, CHECK conditions and unique indexes. If your schema says a balance cannot go negative, the engine refuses the write rather than letting your service decide afterwards.

Isolation means concurrent transactions do not see each other's half-finished work. The default level in most engines is Read Committed; stronger levels such as Repeatable Read and Serializable cost more throughput but prevent certain anomalies. It is the property that lets two services update different rows without stepping on each other, and it is why you sometimes need row locks or an explicit SELECT ... FOR UPDATE.

Durability means a committed transaction survives a crash. The engine has flushed the data to disk — through a write-ahead log on most modern engines — before it acknowledges the commit, so a power cut cannot lose an acknowledged write.

The practical interview point is that ACID is a promise about transactions, not about tables in isolation. A single UPDATE is a one-statement transaction and gets all four properties automatically. Your job is to group statements with BEGIN and COMMIT so that the properties cover the unit of work the business actually cares about.