Chapter 2: Types of Databases — The Landscape

Not all data is the same, and not all access patterns are the same. Different database types optimize for different workloads. This chapter maps the entire landscape so you know what exists and when each type shines.

The Big Categories

1. Relational Databases (RDBMS)

The most important category. Data is organized in tables (rows and columns) with strict schemas and relationships between tables.

-- Table: users
┌────┬─────────┬─────────────────────┬─────┐
│ id │  name   │       email         │ age │
├────┼─────────┼─────────────────────┼─────┤
│  1 │ Alice   │ alice@example.com   │  30 │
│  2 │ Bob     │ bob@example.com     │  25 │
│  3 │ Charlie │ charlie@example.com │  35 │
└────┴─────────┴─────────────────────┴─────┘

-- Table: orders (related to users via user_id)
┌────┬─────────┬────────────┬────────┐
│ id │ user_id │    date    │ amount │
├────┼─────────┼────────────┼────────┤
│  1 │    1    │ 2024-01-15 │  99.99 │
│  2 │    1    │ 2024-02-20 │  49.50 │
│  3 │    2    │ 2024-01-30 │ 199.00 │
└────┴─────────┴────────────┴────────┘

Key properties:

• Strict schema (columns defined upfront)
• ACID transactions
• SQL query language
• Relationships via foreign keys
• Mature, battle-tested (50+ years)

Major players:

2. Key-Value Stores

The simplest model: store and retrieve values by a unique key. Like a giant hash map.

// Conceptually:
SET "user:123" → '{"name":"Alice","email":"alice@ex.com"}'
GET "user:123" → '{"name":"Alice","email":"alice@ex.com"}'
DEL "user:123"

Examples: Redis, Memcached, etcd, DynamoDB

Best for: Caching, session storage, real-time leaderboards, configuration

Limitation: Can only query by key. No "find all users where age > 30."

3. Document Stores

Store semi-structured documents (usually JSON/BSON). Each document can have a different structure.

// MongoDB document — no fixed schema!
{
  "_id": "user_123",
  "name": "Alice",
  "email": "alice@example.com",
  "addresses": [
    {"type": "home", "city": "Stockholm"},
    {"type": "work", "city": "Gothenburg"}
  ],
  "preferences": {"theme": "dark", "lang": "en"}
}

Examples: MongoDB, CouchDB, Firestore

Best for: Content management, catalogs, user profiles with varying fields

Limitation: Weak/no joins, eventual consistency (often), no ACID across documents

4. Column-Family Stores

Optimized for writing and reading large amounts of data across many machines. Data is stored by column, not by row.

// Cassandra: optimized for write-heavy, distributed workloads
// Row key → columns (sparse, can vary per row)
Row "user:123":
  name: "Alice"
  email: "alice@ex.com"
  last_login: "2024-03-15"

Row "user:456":
  name: "Bob"
  phone: "+46701234567"    ← different columns per row!

Examples: Apache Cassandra, HBase, ScyllaDB

Best for: Time-series at scale, IoT data, write-heavy workloads, multi-datacenter

5. Graph Databases

Optimized for data with complex relationships (social networks, fraud detection, knowledge graphs).

Examples: Neo4j, Amazon Neptune, JanusGraph

Best for: Social networks, recommendation engines, fraud detection, network topology

6. Time-Series Databases

Optimized for timestamped data points (metrics, telemetry, IoT sensors).

// Typical time-series data:
timestamp            | metric      | value | host
2024-03-15 10:00:01 | cpu_usage   | 72.5  | server-1
2024-03-15 10:00:01 | memory_used | 8.2GB | server-1
2024-03-15 10:00:02 | cpu_usage   | 73.1  | server-1

Examples: InfluxDB, TimescaleDB, Prometheus, ClickHouse

Best for: Monitoring, IoT, financial data, network telemetry

7. Search Engines

Optimized for full-text search and analytics on unstructured text.

Examples: Elasticsearch, OpenSearch, Solr

Best for: Log analysis, full-text search, analytics dashboards

Decision Guide