Most applications need some form of persistence—a way to store the data outside the application for safekeeping. The most basic way is to write data to the file system, but that can quickly become a slow and unwieldy way to solve the problem. A full-blown database provides a powerful way to index and retrieve data, but it may also be overkill. Sometimes, all you need is a quick way to take a freeform piece of information, associate it with a label, stash it somewhere, and pull it back out again in a jiffy.
Enter the key-value store. It’s essentially a NoSQL database, but one with a highly specific purpose and a deliberately constrained design. Its job is to let you take data (a value), apply a label to it (a key), and store it either in-memory or in some storage system that’s optimized for fast retrieval. Applications use key-value databases for everything from caching objects to sharing commonly used data among application nodes.
Many relational databases can function as key-value stores, but that’s a little like using a tractor-trailer to go on grocery runs. It works, but it’s dramatically inefficient, and there are far lighter ways to solve the problem. A key-value store, like other NoSQL databases, provides just enough infrastructure for simple value storage and retrieval, integrates more directly with applications that use it, and scales in a more granular way with the application workload.
Key-value NoSQL database features compared
Five widely used products (including one cloud service) are worth your consideration; they are explicitly billed as key-value databases or offer key-value storage as a central feature. Their basic differences: