The specialised stores
Lesson 5 of 5 in Choosing a Data Store.
The specialised stores are easy marks, because each one exists for a question the general-purpose stores answer badly, and the stem almost always contains that question in plain words. The work is learning which sentence belongs to which store — and resisting the urge to pick the specialist when the general store would do.
“Ranked by relevance, tolerating typos and word forms.” Amazon OpenSearch Service. An inverted index with analysers can stem, tokenise and score; LIKE can do none of those and cannot say which match is better. It is also where log and trace search lives, with hot, UltraWarm and cold tiers to make a long retention affordable.
“How is this connected to that, at any depth?” Amazon Neptune. The discriminator is an unbounded traversal — "every account reachable from this one through shared devices, however many hops". In SQL that is a recursive join whose cost explodes with depth; in a graph store, traversal is the primitive. Fraud rings, identity resolution and lineage sit here.
“The application already speaks MongoDB / Cassandra.” Amazon DocumentDB and Amazon Keyspaces. These are compatibility answers, not capability answers: for a greenfield key-value or document workload on AWS the default is DynamoDB, and these two are what you reach for when a rewrite is not on the table.
“Microseconds, and it is the source of truth.” Amazon MemoryDB. “Microseconds, and we can rebuild it.” Amazon ElastiCache. That one word — durable or rebuildable — is the whole distinction, and it is the next board.
“Readings over time, downsampled and interpolated.” Amazon Timestream, with a lifecycle caveat worth reading twice: Timestream for LiveAnalytics closed to new customer access on 20 June 2025, and Timestream for InfluxDB is the managed option for new builds.
“Nearest neighbours of an embedding, cheaply, at scale.” Amazon S3 Vectors for cost-first vector storage, OpenSearch for vectors that sit beside keyword search and filters.
| Store | The question only it answers well | What it is NOT for |
|---|---|---|
OpenSearch Service | relevance-ranked text search with typo tolerance and stemming; log and trace exploration over a long retention using warm and cold tiers | a warehouse — aggregations reach only the fields you mapped in advance, and capacity is priced per node rather than per terabyte scanned |
Neptune | traversal of unknown depth: what is reachable from here, and by what path — Gremlin, openCypher or SPARQL | aggregation over millions of rows, which is still a columnar warehouse job |
DocumentDB | an application that already speaks the MongoDB API and must not be rewritten | a reason to move off DynamoDB; for greenfield key-value work DynamoDB is the default |
Keyspaces | an existing Cassandra application, its CQL drivers and its wide-partition model, with no cluster to operate | a greenfield design — the data model it preserves is Cassandra’s, not one you would choose fresh |
ElastiCache | microsecond reads of data whose authoritative copy lives elsewhere — a lookup cache, a dedupe set | anything that cannot be rebuilt; a cache miss must be a survivable event |
MemoryDB | microsecond reads where the in-memory copy IS the source of truth, because writes commit to a multi-AZ log | bulk storage — memory is the dearest gigabyte in the catalogue |
Timestream | time-series readings with native interpolation, downsampling and windowing — for InfluxDB for new builds | a general store; and note LiveAnalytics is closed to new customers as of 20 June 2025 |
S3 Vectors | nearest-neighbour search over embeddings at the lowest storage cost, for retrieval that tolerates lake-shaped latency | sub-millisecond vector lookup beside keyword filters, which is an OpenSearch job |
Does this workload actually want a specialist?
Interactive decision tree — outcomes:
- Amazon OpenSearch Service
Analysers, stemming and relevance scoring are what the stem is describing, and nothing else on AWS has them. Budget for the index being a derived copy that a pipeline has to keep current, and use the warm and cold tiers if the retention is long.
- Amazon Neptune
Unbounded traversal is the discriminator. If the question had a fixed join depth, a relational store would have been the cheaper answer — so check that the stem really says “any depth” and is not just describing a foreign key.
- Amazon ElastiCache
Rebuildable means a cache, and a cache means your capacity planning has to survive an empty one. Decide the eviction policy and the time-to-live deliberately, because a stale cache is a correctness bug rather than a performance one.
- Amazon MemoryDB
Writes commit to a multi-Availability-Zone transaction log before acknowledgement, which is what makes it safe to be the only copy. Accept single-digit-millisecond writes and memory pricing; reads stay in microseconds.
- Stay with a general-purpose store
This is the outcome people skip, and it is right more often than the specialists combined. A fixed-depth relationship is a join, and a key lookup in milliseconds is DynamoDB or Aurora. Introducing a specialised store adds a copy, a pipeline to keep it current, and a second set of failure modes — all of which need a requirement to justify them.
Key terms: Amazon ElastiCache, Amazon MemoryDB, Amazon Neptune, Amazon Keyspaces, Amazon DocumentDB, Amazon Timestream
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.