Key-Value Databases

What problem is this solving?

Some data only needs one fast lookup by a known key.

For that kind of access, tables, joins, and complex query planning can be unnecessary overhead.


Simple definition

A key-value database stores data like a dictionary:

key → value

Popular examples:


Simple Example

session:user_101 → { "loggedIn": true, "role": "admin" }

You ask by key:

session:user_101

The database returns the value.

No joins.

No complex relational model.

Just fast lookup.


Real example

Redis is commonly used for:

Example:

rate_limit:user_101 → 43

If the user sends another request, increment the counter.

If the counter crosses the limit, block or slow down the user.


Better explanation

Use a key-value database when:

Good examples:


When not to use key-value stores

Avoid key-value stores as the main database when:

Example:

An order/payment system should usually not be modeled only as Redis keys.

SQL is a better default there.


Common mistake

Do not use Redis as your main source of truth just because it is fast.

Speed is useful, but if the data needs relationships, durable transactions, and reporting, SQL is usually a better fit.


Interview Answer

If an interviewer asks:

When would you use Redis or a key-value database?

You can answer:

I would use a key-value database when access is mostly by key and speed matters, such as caching, sessions, OTPs, feature flags, and rate limiting. Redis is a common example. It is not a good default for complex relational data because it does not naturally support joins and rich querying like SQL.