Problems with RDBMS

A fintech startup is running smoothly on PostgreSQL. 2 million users. Clean schema. Fast queries. Then they hit 50 million users. Their DBA runs one routine command — ALTER TABLE users ADD COLUMN loyalty_tier VARCHAR(20) — and the entire app freezes for 4 hours. No payments. No logins. No anything. This lesson is about exactly why that happens, and the four other walls you'll hit when you push a relational database past what it was designed for.

What RDBMS Was Built For — and What Changed

Relational databases were engineered in the 1970s around a very specific world: predictable data, moderate scale, strong consistency. Think bank ledgers, employee payroll, inventory counts. That world still exists — and SQL still dominates it.

But the modern web added three things SQL never planned for: unpredictable data shapes, planet-scale write volumes, and the need to spread data across hundreds of machines. Those three things expose five specific cracks in the relational model. Let's look at each one with real code.

Problem 1 — The Schema Lock

In SQL, every row in a table must match the same schema. That sounds reasonable until your product evolves — and products always evolve. Adding a new column to a small table is instant. Adding it to a 200-million-row table is a different story entirely.

The scenario: You're a backend engineer at a payments company. Your product team wants to add a loyalty_tier field to the users table. The table has 180 million rows. Your DBA runs the migration on staging first to check. Here's what happens:

-- Step 1: Check how big the table is before we touch it
SELECT COUNT(*) FROM users;

  count
-----------
 180,442,819

(1 row)
Time: 2340ms

-- Step 2: Add the new column
-- This looks innocent. It is not.
ALTER TABLE users ADD COLUMN loyalty_tier VARCHAR(20);

-- What PostgreSQL does internally:
-- 1. Acquires an ACCESS EXCLUSIVE lock on the table
-- 2. Rewrites every single row to include the new column
-- 3. Updates every index that touches this table
-- 4. Releases the lock

-- Every read AND write to users table is BLOCKED during this time

ALTER TABLE
Time: 14400000ms   -- that's 4 hours

Problem 2 — Join Performance at Scale

Joins are SQL's superpower — and its Achilles heel. A 3-table join on small tables is fast. The same join on tables with tens of millions of rows each starts to crawl. And the data you need is almost always spread across multiple tables.

The scenario: You're building a dashboard for an e-commerce platform. The product manager wants to see each order, the customer name, the product name, the warehouse it shipped from, and the courier assigned. That requires joining 5 tables. Here's what that query looks like:

-- A real dashboard query — 5 table join
SELECT
  o.id          AS order_id,
  u.name        AS customer,
  p.title       AS product,
  w.location    AS warehouse,
  c.name        AS courier
FROM orders o
JOIN users u        ON o.user_id    = u.id
JOIN products p     ON o.product_id = p.id
JOIN warehouses w   ON o.warehouse_id = w.id
JOIN couriers c     ON o.courier_id = c.id
WHERE o.created_at > NOW() - INTERVAL '30 days';

order_id  | customer      | product           | warehouse    | courier
----------+---------------+-------------------+--------------+---------
 10044221 | Priya Sharma  | Wireless Keyboard | London North | DHL
 10044222 | James Okafor  | USB-C Hub         | Manchester   | FedEx
 10044223 | Lin Wei       | Laptop Stand      | London South | UPS
...

(1,204,882 rows)
Time: 38,400ms    -- 38 seconds to load a dashboard

Problem 3 — Vertical Scaling Hits a Ceiling

When a relational database gets slow, the traditional answer is: buy a bigger server. More RAM. Faster CPU. Bigger disk. This works — up to a point. Then you hit the ceiling.

Problem 4 — Forcing Unstructured Data Into Rows

Modern applications live on APIs. Every API returns JSON. And JSON is almost never perfectly flat — it has nested objects, arrays, and optional fields. Stuffing that into SQL tables is a constant battle.

The scenario: You're integrating a third-party payments API. Every transaction comes back as a JSON object with nested billing details. You need to store it. Here's what you get from the API, and the painful workaround SQL forces on you:

// What the payments API gives you — natural JSON
{
  "txn_id": "txn_9982",
  "amount": 149.99,
  "currency": "GBP",
  "billing": {
    "name": "Sara Osei",
    "city": "London",
    "postcode": "E1 6RF"
  },
  "tags": ["online", "card", "3ds-verified"]
}

// In MongoDB — store the API response directly, zero transformation
db.transactions.insertOne({
  txn_id:   "txn_9982",
  amount:   149.99,
  currency: "GBP",
  billing:  { name: "Sara Osei", city: "London", postcode: "E1 6RF" },
  tags:     ["online", "card", "3ds-verified"]
})

Problem 5 — Write Throughput Under Load

SQL databases are built to guarantee that every write is safe, consistent, and immediately visible to every other query. That guarantee has a cost — it requires locks, transaction logs, and disk flushes. At moderate volume, you never notice. At high volume, it becomes a bottleneck.

The scenario: You're running a live sports platform. A major football match just ended. 2 million users click "view result" at the same moment. Your app logs every page view. Here's what your PostgreSQL write log looks like under that load:

-- What PostgreSQL does for every single INSERT:
-- 1. Begin transaction
-- 2. Check constraints (foreign keys, unique, not-null)
-- 3. Acquire row-level lock
-- 4. Write to WAL (Write-Ahead Log) on disk
-- 5. Write actual row to heap
-- 6. Update all relevant indexes
-- 7. Commit and flush to disk
-- 8. Release lock

-- At 50,000 inserts/sec: steps 3-4 become the bottleneck

-- PostgreSQL performance under load (real-world benchmarks):

Writes/sec    Avg latency    Queue depth    Status
----------    -----------    -----------    ------
1,000         2ms            0              Healthy
10,000        8ms            12             Fine
30,000        45ms           340            Degraded
50,000        320ms          2,100          Critical
80,000        timeout        overflowing    System down

All 5 Problems — at a Glance

SQL Is Not the Villain

Everything above is true — and none of it means you should replace SQL with NoSQL everywhere. That would be swapping one set of problems for another.

Practice Questions — You're the Engineer

Quiz — What Would You Do?