The simple structure of DynamoDB and Redis makes these databases extremely scalable. With no connection between values and no construction schemes required, the number of values is limited only by computing power.
That’s why key–value stores are used by hosting providers like ScaleGrid, Compose, and Redis Labs. Often, developers use key–value stores to cache data. These stores are also a good option for storing blog comments, product reviews, user profiles, and settings.
This type of database is optimized for horizontal scaling, which means you need to add more machines to store more data. This is less costly than scaling relational databases but may lead to high utility costs for cooling and electricity.
But the simplicity of key-value stores can also be a disadvantage. With a key–value store, it’s hard or even impossible to perform the majority of operations available in other types of databases. While searching by keys is really fast, it can take much longer to search by values.
In most cases, key-value stores are used in combination with a database of another type. In the Healthfully and KPMG apps we developed, we used the Redis key–value store in combination with the PostgreSQL relational database management system.
Document-oriented databases store all information related to a given object in a single BSON, JSON, or XML file. Documents of the same type can be grouped into so-called collections or lists. These databases allow developers not to worry about data types and strong relations.
A document-oriented database usually has a tree or forest database model. A tree structure means that a root node has one or more leaf nodes. A forest structure consists of several trees. These data structures help document stores perform a fast search. While this makes it difficult to manage complicated systems with numerous connections between elements, it lets developers create document collections by topic or type.