Document, key-value and graph databases: when, and when not

NoSQL means databases not built on tables: document (MongoDB), key-value (Redis) and graph (Neo4j). Each has its own job, and a relational one is the default.

Tables aren’t the only way

So far we have stored data in tables. That’s the most common way, but not the only one. Around 2009 the word NoSQL came into use. It’s usually read as “not only SQL”: databases where data is arranged differently from tables. They didn’t appear out of fashion but out of specific problems. Big sites ran into the fact that one relational database couldn’t keep up with the writes, and that the data of different pages had different shapes. So people began trying other shapes.

A craze followed: “tables are obsolete, put everything in MongoDB”. A few years later the wave ebbed. Relational databases learned to store JSON and to scale, and many of the new databases, on the contrary, added SQL and transactions. The sensible conclusion is that every shape of data has a job where it is best, and almost always there are fewer such jobs than it seems.

Look at the same data from your brief in four shapes and ask it different questions. For each question the diagram rates how comfortably the chosen shape handles it.

TablesDocumentKey-valueGraph

id	title	category_id
1	First service	1
2	Second service	1
3	Third service	2

One table for each kind of “thing”, with links through keys (category_id).

A question for the data: All the services in one categoryWho is connected to whom through shared services, two or three steps awayFind the session of a signed-in visitor by the token in a cookieA visitor counter for today: +1 on every visitEvery service has its own set of fields, read whole in one pieceInquiries that point to a service and contact details, plus a monthly report

Tables: Natural. This is WHERE category_id = … Tables were made for a question like this.

Shape	Rating
Tables	Natural
Document	Possible
Key-value	Awkward
Graph	Possible

Text alternative: for each of the six questions (selecting by category, links several steps deep, a session by token, a counter, a document with arbitrary fields, inquiries with a report) the diagram says which storage shape fits naturally, which tolerably and which awkwardly. The ratings are the lesson author’s judgment, not a measurement.

Document databases

A document database (MongoDB, CouchDB, Firestore) stores documents: usually JSON objects with nesting, each with its own set of fields. A service can be one document with its credentials and its leaders nested right inside.

This is good when:

• a document is read whole, in one piece (a service page takes everything at once);
• records have different fields (one service has a schedule, another doesn’t);
• the schema changes often on the go.

The price. A document has no familiar links: by nesting a service in every inquiry you duplicate it and return to the very “update anomalies” of lesson 3. The “schema” now lives not in the database but in the head of the code: the database won’t stop you writing a price as a string in one document and as a number in another. Reports and joins are harder.

An important caveat: PostgreSQL can do documents. The jsonb type stores JSON in a column, which you can search and index. So a table with one JSON column is often enough for “pieces with any fields”, and a separate database isn’t needed.

Key-value

The simplest shape: a dictionary. A key unambiguously names a value, and that is all. The best-known store of this kind is Redis, which keeps data right in memory and so answers in a fraction of a millisecond.

What it’s taken for:

• sessions: the key is the token from a cookie, the value is what is known about the person, and the entry disappears by itself after half an hour;
• caches: a ready-made page or the result of a heavy query;
• counters and limits: “no more than five sign-in attempts a minute from this address”;
• queues of short tasks.

The price: you can’t search by value (only by key), there are no links, and data in memory may be lost in a crash (this can be configured, but then the speed goes). So Redis is most often a helper to the main database, not a replacement.

Graph databases

When the links are the main thing in the data, a graph fits: nodes (people, services) and edges between them (leads, knows, bought). The best-known graph database is Neo4j. A query reads like a path: “find the people who lead the services that my acquaintances lead”.

It’s a strength for tasks like “friends of friends of friends”, recommendations (“people who bought this also bought…”), finding fraudulent chains, routes. But an ordinary site has links one step deep: a service belongs to a category, an inquiry to a service. An ordinary JOIN handles those, and a graph database isn’t needed here. It’s worth knowing about so that you recognize “your” problem if it ever turns up.

There are other shapes too: column stores for huge analytics (ClickHouse), time series stores for metrics, search engines and vector databases (more on those in the next lesson).

How to choose

Questions worth asking before choosing.

1. What questions will the data be asked? Find by key, walk the links, assemble a report, show whole? The shape of storage should follow from the questions, not from the name of a fashionable database.
2. Do you need transactions and integrity? For inquiries, orders and money, yes. For a visitor counter, no.
3. How much data and load? On a brochure site with a hundred inquiries a year, these questions don’t even arise.
4. Who will look after all this? Every new database is one more server: to start, update, secure, back up and watch. That’s the real price.

This gives a working rule: by default take one relational database (PostgreSQL, or SQLite for the smallest project) and add another when you have measured that you can’t do without it. The engineer Dan McKinley called this “choosing boring technology”: every team has only a few “innovation tokens”, and spending one on an exotic store is sensible only if that’s where you differ from everyone else. For a website that is almost never the case.

Check yourself: for inquiries with contact details and a monthly report, would you choose a document database?

No. An inquiry refers to a service, a report is a grouping by dates and services, and transactions are needed too. All of that is a strong side of a relational database. A document database would make you duplicate the service in every inquiry.

Where the data lives and who can read it

Every non-relational database has its own access settings, and this is where mistakes are made most often. For years, thousands of MongoDB and Redis instances were found open to the internet with no password, because during installation, for the convenience of development, access had not been closed. Data was copied out of them, and sometimes wiped, with a ransom demanded. The rule is simple: a database must not be visible from the internet (the port is closed by a firewall, and only its own server can reach it), it has a password, and the brief records for each feature who reads the data and where it lives. The latter (in which country) comes back in lesson 7: for personal data it’s not a whim but a legal matter.

Practice

You’re in the era of 2022. Sites no longer live on one database: a cache, search and sessions get attached to it. Let’s decide what your project really needs.

The page has a table of five features: a catalog, inquiries, sessions, links between people and a fast counter. For each, choose a store, explain the choice and name the price. Then say where the data lives and who can read it, and show one place where you chose an ordinary relational database despite the temptation.

What was wrong with 2010

In the early 2010s “NoSQL” became a banner: many startups took MongoDB for everything, because it needed no schema and promised endless growth. The growth didn’t come to everyone, but the price (a “schema” in the head of the code, duplicated data, reports by hand) came to all. By the middle of the decade many had gone back to relational databases and brought with them a lesson: choose by the job, not by fashion.