Relational Vs. Non-Relational Databases

Document databases store each record as a document, usually in a format like JSON. Two documents in the same collection can have different fields. A restaurant menu with unusual options fits here without a schema change. MongoDB and Couchbase are examples.

Key-value databases store a value under a key and offer two operations: put and get. They are very fast and very simple, and they cannot search inside the value. Redis is the common example, often used for caching and sessions.

Wide column databases store rows that are grouped into column families, and different rows may hold different columns. They are built to spread very large tables across many machines. Cassandra and HBase are examples.

Graph databases store nodes and the edges between them, and they are built for questions about connections. "Which of my friends know each other" is one query in a graph database and a painful chain of joins in a table. Neo4j is the common example.

ACID, defined

Relational databases are usually described as ACID compliant. ACID is four guarantees a transaction gives you.

Atomicity. All the operations in a transaction happen, or none of them do. There is no half finished transfer.

Consistency. A transaction moves the database from one valid state to another. Every declared rule still holds when it finishes.

Isolation. Transactions running at the same time do not see each other's unfinished work.

Durability. Once a transaction is committed, its changes survive a crash or a power loss.

BASE, defined

Many distributed non-relational systems describe themselves with BASE instead.

Basically available. The system answers requests even when some machines are down, possibly with older data.

Soft state. The stored state may keep changing on its own as machines catch up with each other.

Eventual consistency. If writing stops, all copies agree after some time. Until then, two readers can get different answers.

BASE trades immediate correctness for staying available. That is a good trade for a product catalog and a bad one for a bank balance.

Three claims you will hear that need care

These three appear in blog posts, slide decks, and interview answers. Each one is either wrong or badly out of date, and knowing why marks you out as someone who has actually used both.

"Relational databases can only scale vertically." This is false. Vertical scaling means putting the database on a bigger machine. Horizontal scaling means spreading it across several machines.

Relational databases do scale horizontally. Read replicas spread read traffic across copies. Partitioning, also called sharding, splits one large table across machines by a key. Distributed SQL systems do both while still offering transactions.

The honest statement is about cost, not ability. A join across two machines is far more expensive than a join inside one, and a transaction touching two machines needs extra coordination. Non-relational systems are often easier to spread out because their data models discourage those operations in the first place.

"Non-relational databases do not support transactions." This was mostly true when these systems were new. It is not true now.

Several document and wide column databases support ACID transactions today, though often with limits: one document, one partition, or a measurable performance cost. Check the specific product rather than trusting the category.

"Non-relational databases have no schema." The database does not enforce a schema. That does not mean there is no schema.

Your application still expects a price field holding a number. That expectation is a schema. It has simply moved from the database into the application code, where nothing checks it.

The two approaches have proper names. Schema on write means the database checks data as it arrives. Schema on read means the reader makes sense of whatever it finds. Schema on read makes change cheap and makes bad data easy to store.

Comparison

How to choose

Ask what the data actually looks like and what questions it must answer.

Choose relational when records have a clear, shared structure and relate to each other. Orders, payments, bookings, inventory, and anything where a wrong number is a real problem.

Choose a document database when each record is largely read and written as one whole thing, and the shape varies. Product catalogs, content, user preferences, and menus.

Choose a key-value store when you look items up by one key and nothing else. Sessions, caches, and feature flags.

Choose a graph database when your questions are mostly about connections, and their depth is unpredictable.

Most real systems use more than one. The food delivery app can keep orders and payments in a relational database. It can store menus in a document database and session data in a key-value store. Using different stores for different jobs is called polyglot persistence.

That choice is not free. Each store is another system to run, back up, monitor, and keep in step with the others. Start with one database, and add another only when a real requirement makes you.

💡 In the interview: name the access pattern before naming a product. Say something like: "Orders need transactions across tables, so I would use a relational database. Menus vary in shape and are always read whole, so a document store fits better." If you are asked whether relational databases scale, do not say they scale only vertically. Say they scale out with replicas and sharding, and that the real cost is cross machine joins and transactions. Expect the follow-up "so why not use one database for everything?" and answer with the operational cost of running two.

Key takeaway: the choice is about the shape of the data and the questions asked of it, not about one technology being modern and another being old. Relational databases give you enforced structure, joins, and transactions across tables, and pay for it with harder horizontal scaling. Non-relational databases give you flexible shapes and easier spreading across machines, and move the job of enforcing structure into your application code. This course teaches the relational side, because its design rules are exact and because they remain the foundation most systems are built on.