A key-value store, or key-value database, is a data storage paradigm designed for storing, retrieving, and managing associative arrays, a data structure more commonly known today as a dictionary or hash. Dictionaries contain a collection of objects, or records, which in turn have many different fields within them, each containing data. These records are stored and retrieved using a key that uniquely identifies the record, and is used to quickly find the data within the database.

Key-value stores work in a very different fashion from the better known relational databases (RDB). RDBs pre-define the data structure in the database as a series of tables containing fields with well defined data types. Exposing the data types to the database program allows it to apply a number of optimizations.

In contrast, key-value systems treat the data as a single opaque collection which may have different fields for every record. This offers considerable flexibility and more closely follows modern concepts like object-oriented programming. Because optional values are not represented by placeholders as in most RDBs, key-value stores often use far less memory to store the same database, which can lead to large performance gains in certain workloads.

Performance, a lack of standardization and other issues limited key-value systems to niche uses for many years, but the rapid move to cloud computing after 2010 has led to a renaissance as part of the broader NoSQL movement. A subclass of the key-value store is the document-oriented database, which offers additional tools that use the metadata in the data to provide a richer key-value database that more closely matches the use patterns of RDBM systems. Some graph databases are also key-value stores internally, adding the concept of the relationships (pointers) between records as a first class data type.

Types and Notable Examples

Key-value stores can use consistency models ranging from eventual consistency to serializability. Some support ordering of keys. Some maintain data in memory (RAM), while others employ solid-state drives or rotating disks.

The Curse of the Name-Value Pair

Redis was the most popular implementation of a key-value database as of August 2015, according to DB-Engines Ranking.

Another example of key-value database is Oracle NoSQL Database. Oracle NoSQL Database provides a key-value paradigm to the application developer. Every entity (record) is a set of key-value pairs. A key has multiple components, specified as an ordered list. The major key identifies the entity and consists of the leading components of the key. The subsequent components are called minor keys. This organization is similar to a directory path specification in a file system (e.g., /Major/minor1/minor2/). The "value" part of the key-value pair is simply an uninterpreted string of bytes of arbitrary length.

The Unix system provides dbm (DataBase Manager) which is a library originally written by Ken Thompson. The dbm manages associative arrays of arbitrary data by use of a single key (a primary key). Modern implementations include ndbm, sdbm and GNU dbm.

Reasons to Use

Supports simple queries very efficiently. Very simple data-modeling pattern, should be understandable by anyone. Your "data model" is super flexible. Name-Value pair tables are extensible. If you add more attributes to describe an existing entity, you grow vertically within the table, no new attributes need to be added.

Reasons not to Use

The only queries that are efficient are simple, one-row-at-a-time queries. Not really a data model at all, in that there's no association between attributes that form an entity. Hard to use most ordinary SQL operations such as JOIN or GROUP BY. You can't choose an appropriate SQL data type for the value. You can't use many SQL constraints such as FOREIGN KEY or NOT NULL. Pivoting the result to resemble a conventional result (one column per attribute) is a complex and expensive query. You have to write a lot more application code to reassemble collections of key/value pairs into objects. Access to and around that data model is second class and strictly inferior to your native data model.