> For the complete documentation index, see [llms.txt](https://blog.gomchik.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blog.gomchik.com/books/seven-databases-in-seven-weeks/genres-of-databases.md).

# Genres of databases

> **Don’t ask:** Can I use this database to store this data ?
>
> **Ask:** Should I use this database to store this data?

It’s important to remember that most of the data problems you’ll face could be solved by most or all of the databases in this book, not to mention other databases. The question is less about whether a given database style could be shoehorned to model your data and more about whether it’s the best fit for your problem space, your usage patterns, and your available resources. You’ll learn the art of divining whether a database is intrinsically useful to you.

* **Relational Databases**
  * Relational database management systems are set-theory-based systems implemented as two-dimensional tables with rows and columns
  * Data values are typed and may be numeric, strings, dates, uninterpreted blobs, or other types
  * Tables can join and morph into new, more complex tables because of their mathematical basis in relational (set) theory
  * examples: MySQL, H2, HSQLDB, SQLite, **PostgreSQL**
* **Key-Value**
  * A KV store pairs keys to values in much the same way that a map (or hashtable) would in any popular programming language.
  * Because the KV moniker demands so little, databases of this type can be **incredibly performant** in a number of scenarios but generally **won’t be helpful when you have complex query and aggregation needs**
  * examples: memcached, memcachedb, membase, Voldemort, **Redis**, **Riak**
* **Columnar**
  * data from a given column is stored together. 
  * adding columns is quite cheap and is done on a row-by-row basis. 
  * Each row can have a different set of columns, or none at all, allowing tables to remain sparse without incurring a storage cost for null values. 
  * With respect to structure, columnar is about midway between rela- tional and key-value.
  * examples: HBase, Cassandra, Hypertable.
* **Document**
  * Different document databases take different approaches with respect to **indexing, ad hoc querying, replication, consistency, and other design decisions**. Choosing wisely between them requires understanding these differences and how they impact your particular use cases.
  * examples: MongoDB, CouchDB
* **Graph**
  * graph databases excel at dealing with highly interconnected data. 
  * A graph database consists of nodes and relationships between nodes. 
  * Both nodes and relationships can have properties (as key-value pairs) that store data. 
  * The real strength of graph databases is traversing through the nodes by following relationships.
* **Polyglot**
  * In real world, databases of one type are often used alongside databases of other types. 
  * It’s still common to find a lone relational database, but over time it is becoming popular to use several databases together, leveraging their strengths to create an ecosystem that is more powerful, capable, and robust than the sum of its parts. This practice is known as polyglot persistence.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://blog.gomchik.com/books/seven-databases-in-seven-weeks/genres-of-databases.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.