Key value store definition, examples, and uses

Takeaways

What is a key-value store?

A key value store is a NoSQL database that maps a unique key to a value and retrieves that value through a direct lookup rather than a query. The application sends a key, the store returns the value, and that is the entire interaction. There is no query language to parse, no execution plan to build, and no tables to join.

This simplicity is the whole point. Because the store only ever answers one question, "what is the value for this key," it can answer that question in microseconds and scale horizontally by spreading keys across as many nodes as you need. Relational databases spend their time on flexibility. A key-value store database spends its time returning data.

How key-value pairs work

The key is a unique string, often built from a namespace and an identifier, such as a session ID or a user ID. The value is opaque to the store. It can be a string, a JSON document, a serialized object, or raw binary. The store does not inspect the value or index its contents. It hashes the key, finds the location, and returns whatever sits there.

That hashing step is what gives key-value stores their O(1) average lookup time. The cost of a read stays flat whether the store holds a thousand pairs or a billion. A typical operation looks like this:

Storage happens in one of two places. In-memory stores like Redis and Memcached keep every pair in RAM for the fastest possible reads. Disk-backed stores like DynamoDB persist pairs to durable storage and accept slightly higher latency in exchange for durability and capacity beyond what memory allows.

Key-value stores vs. relational databases

A relational database organizes data into tables with fixed schemas and lets you ask arbitrary questions with SQL. A key-value store database organizes nothing. It holds pairs, and it answers exactly one question per request. That constraint is a feature when your access pattern is known in advance, because the store skips all the machinery a relational engine needs to support ad hoc queries.

The trade-off cuts both ways. If you need to find every order above $500 placed last week, a key-value store cannot help you without scanning everything. If your workload genuinely needs relational queries but still demands low latency, running SQL at the edge is a better answer than forcing a key-value model onto relational data.

Advantages and limitations

The practical case for key-value stores comes down to three properties, and the case against them comes down to what the simple model gives up.

Key-value store examples

The category spans everything from pure caches to globally replicated managed services. These key-value database examples cover the four you will encounter most often, with an honest look at where each one fits and where it does not. Redis gets its own section below, because it dominates the category enough to deserve one.

Amazon DynamoDB

Amazon DynamoDB is AWS's fully managed key-value and document database. You define a table, pick a partition key, and AWS handles replication, scaling, and failover. It follows the serverless database model, so you pay per request rather than provisioning servers, and it holds up under enormous write volumes without operational work on your side.

The trade-offs are lock-in and cost. DynamoDB only runs on AWS, its query patterns must be designed around the partition key up front, and per-request pricing that looks cheap at low volume gets expensive at sustained high throughput. Teams that outgrow the free tier often discover the bill scales faster than the traffic.

etcd

etcd is a distributed key-value store built for one job: holding the configuration and coordination state that distributed systems depend on. It uses the Raft consensus algorithm to guarantee strong consistency across nodes, which is why Kubernetes uses it as the source of truth for every cluster. When you need every node to agree on a value, etcd is the standard answer.

That consistency comes at the cost of throughput. Every write must be acknowledged by a quorum of nodes, so etcd is deliberately slow compared to a cache. It is the right store for service discovery, leader election, and cluster config. It is the wrong store for session data, user records, or anything high-volume.

Memcached

Memcached is the simplest key value store example on this list. It is a pure in-memory cache with a flat keyspace, multithreaded performance, and nothing else. No persistence, no replication, no data structures beyond strings. That minimalism makes it easy to reason about and cheap to run, and it still powers caching layers at some of the largest sites on the internet.

The drawback is the flip side of the design. When a Memcached node restarts, its data is gone, and your database absorbs the full read load until the cache warms back up. Treat it strictly as a disposable read accelerator, never as a system of record.

Common use cases for key-value databases

Look at where key-value stores actually run in production and a pattern emerges. Caching database query results. Holding session state and shopping carts. Serving user preferences and feature flags. Powering real-time leaderboards with sorted sets. Acting as a fast metadata layer beside an embeddings database in AI retrieval pipelines, where the vector search finds candidates and the key-value lookup fetches the full records.

Nearly every workload on that list shares one trait: it sits in the hot path of a user request. A session lookup happens on every page load. A feature flag check happens on every API call. These reads are measured in milliseconds, which means the network distance between the user and the store often costs more than the lookup itself. That fact matters more than most database comparisons admit, and it is where this article ends up.

Redis as a key-value store

Why Redis dominates the key-value category

Redis is the default answer when developers reach for a key value store, and the reasons are concrete. It keeps everything in memory, so reads and writes complete in well under a millisecond. It goes beyond plain key-value pairs with native data structures, including lists, sets, sorted sets, and hashes, which means a leaderboard or a rate limiter is a single command instead of application logic. It adds pub/sub messaging on top, so the same process that caches your data can also fan out events.

Unlike Memcached, Redis can also survive a restart. It offers two persistence modes, RDB snapshots for point-in-time backups and AOF logging for replaying every write, and you can combine them. The Redis documentation covers both in detail. The result is a store fast enough to be a cache and durable enough to hold data you would rather not lose.

Redis limitations to consider

Memory is the first constraint. RAM costs far more per gigabyte than disk, so a Redis dataset that grows into the hundreds of gigabytes gets expensive quickly. The second is the single-threaded core. One Redis process executes commands on one thread, which keeps the model simple but caps throughput per instance and turns one slow command into a queue of blocked requests. Scaling past either limit means Redis Cluster, and self-hosting a cluster brings sharding, failover testing, and version upgrades onto your team's plate.

There is a quieter limitation that benchmarks never show. A self-managed Redis deployment lives in one region, and its sub-millisecond reads only apply to users near that region. Every user on another continent pays the full network round trip before Redis even sees the key. The store is fast. The path to it is not.

Run your key-value store at the edge with Telnyx

Picking the right key value store solves half the latency problem. The other half is geography. A lookup that resolves in 500 microseconds inside the datacenter still arrives slowly if the request crossed an ocean to get there, because no database can optimize away the speed of light. For global applications, where the data lives determines what users actually feel.

Telnyx KV Storage addresses the geography directly. It runs on the Telnyx-owned global network, co-located with compute at the edge, so key-value lookups resolve milliseconds from the end user instead of routing back to a single home region. It follows the same principle as an edge database: move the data to the request instead of the request to the data.

Choose Telnyx KV Storage if:

• Your users are spread across regions and a single-region cache leaves most of them paying for distance.
• You want managed key-value storage without running, sharding, and upgrading your own cluster.
• Your lookups sit beside compute, so the data and the code that reads it belong in the same places.
• You would rather consolidate storage, compute, and communications on one API and one bill than add another vendor.

The comparison worth making is not Redis versus DynamoDB. It is a single-region deployment you maintain versus a distributed one you do not. One platform, one API, and zero cluster management puts your session state, feature flags, and cached lookups next to your users without adding a vendor or an ops rotation to get there.

FAQ