RDBMS Benefits and Limitations
A payments team is choosing where to store money transfers. A transfer must take money from one account and add it to another — never just one half. Another team is storing clickstream events: billions of small records a day, never edited. The same database will not be the best answer for both, and knowing why is the point of this lesson.
The rule
Structure buys trust; you pay for it in rigidity and scaling effort.
A relational database management system (RDBMS) such as PostgreSQL, MySQL, SQL Server or SQLite gives you strong guarantees because it insists on structure up front.
What structure buys you:
- Transactions. Several changes succeed or fail together. Either both halves of the transfer happen, or neither does.
- Constraints. The database itself refuses bad data: a negative price, an order for a customer who does not exist, two customers with the same id.
- Flexible questions. Because data is split into clean tables, you can ask questions nobody planned for, joining tables in new ways years later.
- Maturity. Decades of tooling, backups, replication and people who know it well.
What it costs you:
- A fixed shape. Every row in a table has the same columns. Changing the shape means a migration, which on a huge table takes planning.
- Scaling writes is harder. One server can go a long way, but spreading writes across many machines (sharding) is extra work compared with databases built for it.
- Awkward fits. Data whose shape varies wildly from record to record, or that is naturally a deep tree, can feel forced into rows and columns.
BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE account_id = 1;
UPDATE accounts SET balance = balance + 500 WHERE account_id = 2;
COMMIT;The shortcut
Ask three questions about the data. Each "yes" is a vote for an RDBMS:
- Is the shape stable — do most records have the same fields?
- Must it always be correct, like money, stock or bookings?
- Will people ask new questions of it later?
Stable shape?
Every order has a customer, a product, a quantity and a date. Yes.
If the answers are "no, no, no" — varied shapes, loss-tolerant, one fixed lookup pattern at huge volume — the costs start to outweigh the benefits.
Drills
Answer fast — trust the rule.
A bank transfer must debit one account and credit another, never only one of the two. Which RDBMS feature guarantees this?
Which of these is a genuine limitation of a typical RDBMS?
Which is NOT a typical benefit of a relational database?
A catalogue sells phones, shoes and books, and each has a completely different set of attributes. Why is this awkward for plain relational tables?
Remember
- Structure buys trust; you pay for it in rigidity and scaling effort.
- Three votes: stable shape, must be correct, new questions later.
- Relational does not mean slow or small — it means you declare the shape first.