Other Types of Databases

Relational databases are extremely common, but they are not the only way to store persistent data. Some alternatives are broad storage families, while others are more specialized around a certain data shape or query pattern.

In this chapter, we briefly survey a few of these other database families. The sketches below are intentionally simplified. Their goal is not to show the full implementation details of each database family, but to make the stored data shape easier to notice at a glance.

Although we visit other types of databases here, the main focus of the course is relational databases. The relational model provides a strong foundation for learning data structure, querying, and design, even though some workloads are better served by more specialized systems.

Key-Value Databases

A key-value database stores values behind keys.

This is a good fit when the application mostly needs simple lookup by identifier. For example, a course platform might store a session token or a temporary cache entry under one key and retrieve it quickly later.

Typical questions might be:

• What session token is stored for user 42?
• What cached page is stored for course CS-A1150?

One commonly used example of a key-value database is Redis.

Document Databases

A document database stores structured documents, often in JSON-like form.

This can be convenient when records naturally look like nested documents and when the structure may vary somewhat from one document to another. For example, rich exercise descriptions with optional metadata, rubric details, and attachments might be easier to represent as documents than as a large number of relational columns.

Typical questions might be:

• What does the full exercise document for Query Basics look like?
• Which attachments are stored inside this exercise document?

One commonly used example of a document database is MongoDB.

Wide-Column Databases

A wide-column database groups data by a row key and allows rows to contain a large number of columns, often with somewhat sparse structure.

This can be useful when the system needs to store very large amounts of data under keys such as user, device, or tenant, and when fast access by that key matters more than rich relational joins. For example, an educational platform might keep a very large history of activity events grouped by user or course instance.

Typical questions might be:

• What activity events do we have for user 42?
• What activity records are stored under this course-instance key?

One commonly used example of a wide-column database is Apache Cassandra.

Graph Databases

A graph database emphasizes nodes and connections between them.

This is useful when relationships are the central feature of the data, for example in social networks, recommendation systems, or route planning. In an educational setting, a graph could represent prerequisite relationships between topics or courses.

Typical questions might be:

• Which topics are prerequisites for this course?
• What courses become reachable after completing Databases?

One commonly used example of a graph database is Neo4j.

Time-Series Databases

A time-series database is designed for data points that are primarily organized by time.

This is useful when the system stores measurements, logs, or events and later needs to ask questions such as what happened over a certain time window or how values changed over time. Examples include server metrics, sensor readings, application response times, or submission activity counts across days.

Typical questions might be:

• How many submissions arrived each hour today?
• How did server response time change during the last 15 minutes?

One commonly used example of a time-series database is InfluxDB.

Vector Databases

A vector database is designed for storing vectors and searching for items that are similar to one another in meaning or content.

y
^
|                    help_article_B
|               help_article_A
|          course_description
|
|  cache_token
+----------------------------------> x

This is useful when the system needs similarity search rather than exact matching. For example, a learning system might want to find course descriptions, feedback comments, or help articles that are most similar to a student’s question after those texts have been turned into vector embeddings.

Typical questions might be:

• Which help articles are most similar to this student’s question?
• Which course descriptions are semantically closest to this topic?

One commonly used example of a vector database is Pinecone.

Check Your Understanding

1. When might a key-value store be simpler than a relational schema?
2. What kind of problem can make a document or wide-column database attractive?
3. Why can graph databases be attractive for relationship-heavy problems?
4. Why can time-series and vector databases each be useful for their own kind of query?