DEV Community

Cover image for DynamoDB vs Elasticsearch
DynoTable
DynoTable

Posted on • Edited on • Originally published at dynotable.com

DynamoDB vs Elasticsearch

#dynamodb #aws #database #nosql

Is DynamoDB an alternative to Elasticsearch?

Not really — they solve different problems and are usually used together. DynamoDB is a serverless NoSQL operational database (a key-value and document store) built for low-latency reads and writes at scale. Elasticsearch is a distributed search and analytics engine built for full-text search, aggregations and relevance ranking. A common pattern keeps DynamoDB as the system of record and streams changes into Elasticsearch (or OpenSearch) for search.

Characteristic DynamoDB Elasticsearch
Primary purpose Operational (OLTP) key-value / document store Search and analytics engine over your data
Data model Key-value and document items with attributes JSON documents indexed for search
Query type Key and secondary-index lookups, Query/Scan, PartiQL Full-text queries, filters, aggregations, vector search
Consistency Eventually or strongly consistent reads; ACID transactions Near real-time (refresh-based) visibility of new writes
Durability / role Serverless system of record, replicated across three Availability Zones Distributed search layer, commonly fed from a source of truth
Secondary indexes Global and local secondary indexes Inverted index (fields indexed for search)
Scaling / ops Fully managed, serverless; scales to any size, no servers to run Distributed cluster of shards and replicas; managed or self-hosted
Pricing model Pay for read/write requests plus storage (on-demand or provisioned) Cluster/node capacity or managed-service pricing

When to use DynamoDB

Choose DynamoDB when your workload is operational: high-volume reads and writes against known access patterns, where you need predictable single-digit-millisecond latency, a durable system of record, and no servers to manage. AWS describes it as "a serverless, fully managed, distributed NoSQL database" that supports both key-value and document data models, with strong read consistency and ACID transactions available when you need them. It is a fit for user profiles, sessions, shopping carts, leaderboards, event ledgers, and metadata — anything you fetch by key or a well-planned index.

DynamoDB does not provide relational JOINs or a full-text query engine, and its Scan reads the whole table, so ad-hoc "find any document containing this phrase" queries are not its strength. See Query vs Scan for why access-pattern design matters.

When to use Elasticsearch

Choose Elasticsearch when the job is search or analytics: full-text queries with relevance ranking, fuzzy matching, autocomplete, faceted filtering, log and observability analytics, or aggregations across large volumes of documents. Elastic describes Elasticsearch as "an open source, distributed search and analytics engine built for speed, scale, and AI applications" that stores structured, unstructured, and vector data in real time. It builds an inverted index over your fields so it can find matching documents quickly without scanning everything, and it exposes aggregations for analytical rollups.

Elasticsearch is typically operated as a cluster (self-hosted, on Elastic Cloud, or as the OpenSearch fork on Amazon OpenSearch Service) and is usually kept in sync from a system of record rather than serving as the sole durable store for critical transactional data.

Using them together

The two are complementary, and AWS supports a first-party path to combine them. DynamoDB Streams capture every item-level change in near-real time, and a zero-ETL / OpenSearch Ingestion pipeline replicates that change stream into an Elasticsearch-compatible search index. DynamoDB stays the source of truth serving your key-based operational traffic; the search index answers full-text, fuzzy, and vector queries. AWS notes the integration "does not use read or write throughput on your table," so search does not compete with production traffic.

What an Elasticsearch match query becomes in DynamoDB

Product search in Elasticsearch is one request:

{
  "query": {
    "multi_match": {
      "query": "wireless noise cancelling",
      "fields": ["title^3", "description"],
      "fuzziness": "AUTO"
    }
  },
  "size": 10
}
Enter fullscreen mode Exit fullscreen mode

Four things happen server-side there. The query text is analyzed into terms,
those terms are looked up in an inverted index, AUTO fuzziness tolerates edits
scaled to term length, and title^3 weights title matches above description
matches when Elasticsearch computes _score and sorts by it.

DynamoDB has none of the four. No inverted index, no analyzer, no _score, and
no way to order results by relevance. The closest expressible thing is a
substring test in a filter on a Scan:

{
  "TableName": "products",
  "FilterExpression": "contains(#t, :q) OR contains(#d, :q)",
  "ExpressionAttributeNames": {"#t": "title", "#d": "description"},
  "ExpressionAttributeValues": {":q": {"S": "noise cancelling"}}
}
Enter fullscreen mode Exit fullscreen mode

That request fails in three separate ways, and only the first is obvious.

It is not search. contains tests a raw substring against the stored string, so
"cancelling" never matches a title reading "cancellation", and "wireless noise
cancelling" never matches "noise-cancelling wireless". Every tokenization and
stemming decision Elasticsearch made on your behalf is gone, and no rewrite of
the filter brings it back.

It bills for the whole table. AWS is explicit that a filter expression is applied
after the Scan finishes but before results are returned, so a Scan consumes
"the same amount of read capacity, regardless of whether a filter expression is
present". A search matching nothing costs what a search matching everything
costs. Read 20 GB eventually consistent and that is roughly 2.6 million read
request units, about $0.33 per search at the us-east-1 on-demand rate.

It cannot be one call. The 1 MB result limit applies before the filter is
evaluated, which makes that same 20 GB table around 20,000 sequential round
trips, most of them returning Count: 0 next to a LastEvaluatedKey and no
matches.

AWS's own answer to full-text search over DynamoDB is a second system: stream the
table into OpenSearch and query there. No client-side tool changes that, DynoTable
included. An inverted index has to be built by something that stores one.

Working with DynamoDB

Once you have chosen DynamoDB, DynoTable is a desktop client for working with your tables directly: browse and edit items, build key and filter conditions, and run queries without hand-writing JSON in the console. When you do need to hand-write an expression — a KeyConditionExpression, FilterExpression, or UpdateExpression — the free DynamoDB Expression Builder generates correct syntax with the required expression-attribute name and value placeholders, and emits it for the AWS SDKs, the CLI, and PartiQL.

DynoTable is a closed-source commercial app; it talks to DynamoDB through your standard AWS credentials and does not route your data through any third-party service.

FAQ

Can DynamoDB do full-text search?

Not natively. DynamoDB retrieves items by primary key or secondary index and can filter results, but it has no inverted index or relevance ranking, and Scan reads the entire table. For full-text search, AWS's recommended path is to stream DynamoDB changes into a search engine such as Elasticsearch or Amazon OpenSearch Service and query there.

Should I replace Elasticsearch with DynamoDB?

Usually not — they are built for different jobs. DynamoDB is an operational database for key-based reads and writes; Elasticsearch is a search and analytics engine. If your only use of Elasticsearch is simple key lookups, DynamoDB may cover it, but if you rely on full-text search, aggregations, or relevance ranking, keep Elasticsearch and feed it from DynamoDB rather than replacing it.

Is Elasticsearch a database?

Elastic describes Elasticsearch as an open source, distributed search and analytics engine that can also serve as a data store and vector database. In practice most architectures treat it as a search and analytics layer kept in sync from a primary system of record (like DynamoDB), rather than as the sole durable store for critical transactional data.

Related

References

Last verified 2026-07-13 against the AWS DynamoDB Developer Guide and Elastic's official documentation. Elasticsearch is a trademark of Elasticsearch B.V.; referenced here for identification only.

Top comments (0)