Amazon DynamoDB

Name: Amazon DynamoDB
Brand: Amazon Web Services (AWS)

Leader

Official Global LinkedIn page for Amazon Web Services (AWS).

Est 2006|Valuation $2560B|31 Ref Customers

LinkedIn 10.9M|Website|Web traffic 1.1M|FTEs 148,001|HQ Seattle, Washington, US

Published Oct 15, 2026

01Common complaints

- Workloads better served by relational databases - For domains that are inherently relational (complex joins, reporting queries, transactional workflows that map naturally to SQL), a relational database (e.g., Aurora/Postgres) is often simpler to model and may be more cost-effective from a product-engineering perspective. - Early-stage teams without clear access patterns - When application query patterns are still evolving and frequent schema and query changes are expected, DynamoDB modeling and index strategy can cause repeated rework. - Organizations with limited AWS experience - If the team lacks practical AWS experience, DynamoDB’s API and operational model can still present a steep learning curve related to partitioning, hot keys, indexes, capacity, and cost controls. - Multi-cloud portability requirements - When a database must move between clouds or on-premises with minimal changes, options such as MongoDB, Cassandra, or managed Postgres variants may reduce vendor lock-in. - Budget constraints with uncertain traffic - When the organization cannot tolerate billing variability, fixed-price instances or systems with simpler cost envelopes may be preferable. - Need for flexible querying/search - When rich filtering, full-text search, or analytics-like queries are first-class requirements, adding specialized systems (OpenSearch, Athena, Redshift) may be necessary and increase architectural complexity. - Data modeling constraints - No native joins; relational queries typically require application-level joins or precomputed/materialized views. - Single-table design complexity - Modeling for DynamoDB differs from relational design; teams report both successful outcomes and maintainability challenges. - Cost management - Costs can rise unexpectedly with: - Hot partitions (poor partition key choice) - High write rates combined with multiple GSIs - Global Tables replication - Misconfigured provisioned capacity - Roadmap / future features - AWS continually evolves DynamoDB; roadmap timelines are not always publicly committed. Buyers should validate needed features against current documentation and service announcements.

02Why they buy

- Competitive advantages observed in customer feedback and community discussions - Some reviewers describe DynamoDB as a mature, reliable service that is commonly used in AWS-native architectures. - Operational model reduces certain database administration activities for teams that align with its access-pattern-driven design. - Unique features and capabilities competitors implement differently - Tight integration into AWS event-driven architectures (Streams + Lambda) is frequently cited as an advantage for serverless designs. - Differentiation from competitors based on reviews - DynamoDB is often noted for operational characteristics and predictable performance for primary-key access patterns; competitors are preferred for query flexibility (MongoDB) or multi-API/multi-model patterns (Cosmos DB). - Areas where competitors clearly have advantages - Cosmos DB: multi-API / query options and Azure ecosystem alignment. - MongoDB Atlas: richer document querying and developer familiarity. - Bigtable: suitability for very large-scale wide-column workloads and certain analytics integrations on GCP.

03Field reports

Customer Testimonials

Note: Review platforms aggregate many reviews; the items below summarize recurring themes observed in public reviews and community discussions. - Review platforms (G2, TrustRadius, Gartner Peer Insights) — common themes observed - Positive themes frequently cited - Managed nature of the service reduces operational overhead for some customers - Performance at scale for key-value workloads is commonly reported - Integration with AWS services (Lambda/Streams/IAM) is frequently mentioned as a practical advantage - Negative themes frequently cited - Steep learning curve for data modeling and index design - Cost surprises, particularly when access patterns are not modeled correctly or when using global replication and multiple indexes - Not a good fit for ad-hoc queries, joins, and relational reporting - Community commentary (summary of accessible public discussions) - Some contributors note that for organizations that do not have very large-scale throughput requirements, a relational database may satisfy needs with less custom application-level logic and simpler data modeling. - Other contributors recognize DynamoDB's engineering maturity and prevalence in AWS-native architectures. - Several community posts highlight that single-table design can increase cognitive overhead for some teams and complicate operations and tooling (for example, visibility within the console). - Pricing sentiment: multiple community threads express that DynamoDB can be more expensive than expected when compared with simpler databases, and that managed databases trade operational effort for higher service costs in certain scenarios. - Why customers chose DynamoDB over alternatives (recurring decision drivers) - Fit for predictable access patterns with high throughput - Managed service characteristics reduce certain operational responsibilities - Native AWS integrations for event-driven/serverless architectures - Why some customers leave or avoid DynamoDB (common churn/avoidance reasons) - Requirement for relational querying, joins, complex filters, and flexible analytics - Organizational difficulty adopting single-table/denormalized modeling - Cloud/provider lock-in concerns when multi-cloud portability is a priority - Cost unpredictability if access patterns are not carefully managed

Genesys case study (AWS-published)

AWS describes Genesys using DynamoDB as part of a data tier and states a vendor-published availability figure.

Critical evaluation

The availability figure is presented in a vendor customer story; the measurement period, methodology, and what components are included/excluded are not fully transparent in the public case study. Treat the metric as vendor-published unless independently verified.

Venmo case study (AWS-published)

AWS reports that Venmo achieved a significant cost reduction and improved scalability by migrating a critical database to DynamoDB.

Critical evaluation

The reported cost reduction is a strong claim but appears in a vendor case study context; without detailed baseline configuration, workload mix, and cost model, it is difficult to generalize. It may reflect a specific before/after architecture and assumptions rather than typical outcomes.

What’s missing / harder to find

Detailed technical case studies that include implementation challenges, data modeling missteps, redesigns, and cost overruns are less common in official vendor materials. Community posts and threads sometimes call for more technical transparency and post-mortem detail.

04Best fit

Ideal Customer Profile

- Company sizes - Strongest fit often appears in: - Mid-market to large enterprises running significant production workloads on AWS - Startups that prioritize serverless speed and scale, provided their data model and access patterns are well understood - Industries and verticals - Common usage across: - Fintech/payments (vendor case study: Venmo) - SaaS and cloud software - Customer experience/contact center platforms (vendor case study: Genesys) - Gaming, adtech, IoT, and high-volume telemetry - Roles and personas - Decision makers - Head of Engineering, VP Engineering, Chief Architect, Platform/Infrastructure leaders - End users - Backend engineers, serverless developers, SRE/platform teams - Pain points and challenges the product addresses - Scaling operational workloads while reducing server management - Handling spiky or unpredictable traffic (especially with on-demand) - Building event-driven systems using Streams and Lambda patterns - Qualification criteria: what makes a GOOD fit - Known and stable access patterns - Need for high throughput and low latency - AWS-first strategy and willingness to use AWS-native tooling - Data model can be denormalized effectively - Deal disqualifiers: what makes a POOR fit - Requirements for ad-hoc analytics queries, joins, or complex relational constraints - Rapidly changing access patterns that would force repeated re-modeling - Strong need for multi-cloud portability with minimal re-platforming - Real customer examples - Genesys (AWS case study) - Venmo (AWS case study)

05The pitch

What the product does (core value proposition in objective terms)

- Amazon DynamoDB is a fully managed, serverless NoSQL database that targets low, predictable millisecond latency for key‑value and document access patterns at scale. It is positioned as an operational datastore for high‑throughput applications rather than as a general-purpose relational database. (Official positioning: “fast NoSQL key-value database.”) - Core building blocks include tables, partition keys/sort keys, secondary indexes (GSI/LSI), Streams for change data capture, TTL for expiry use cases (e.g., sessions), and optional in-memory acceleration via DAX.

Target market and market positioning

- Target users are teams building cloud-native applications (often AWS-centric) that need: - Very high request volume with low operational overhead - Simple query patterns (primary key / range key) and denormalized data models - Integration with AWS services (Lambda, API Gateway, Kinesis, S3, CloudWatch, IAM) - Market positioning: managed/serverless NoSQL with emphasis on operational characteristics, autoscaling options, and AWS ecosystem integration.

Get a comprehensive analysis of Amazon DynamoDB including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Published Oct 15, 2026

01Common complaints

Workloads better served by relational databases
- For domains that are inherently relational (complex joins, reporting queries, transactional workflows that map naturally to SQL), a relational database (e.g., Aurora/Postgres) is often simpler to model and may be more cost-effective from a product-engineering perspective.
Early-stage teams without clear access patterns
- When application query patterns are still evolving and frequent schema and query changes are expected, DynamoDB modeling and index strategy can cause repeated rework.
Organizations with limited AWS experience
- If the team lacks practical AWS experience, DynamoDB’s API and operational model can still present a steep learning curve related to partitioning, hot keys, indexes, capacity, and cost controls.
Multi-cloud portability requirements
- When a database must move between clouds or on-premises with minimal changes, options such as MongoDB, Cassandra, or managed Postgres variants may reduce vendor lock-in.
Budget constraints with uncertain traffic
- When the organization cannot tolerate billing variability, fixed-price instances or systems with simpler cost envelopes may be preferable.
Need for flexible querying/search
- When rich filtering, full-text search, or analytics-like queries are first-class requirements, adding specialized systems (OpenSearch, Athena, Redshift) may be necessary and increase architectural complexity.
Data modeling constraints
- No native joins; relational queries typically require application-level joins or precomputed/materialized views.
Single-table design complexity
- Modeling for DynamoDB differs from relational design; teams report both successful outcomes and maintainability challenges.
Cost management
- Costs can rise unexpectedly with:
  - Hot partitions (poor partition key choice)
  - High write rates combined with multiple GSIs
  - Global Tables replication
  - Misconfigured provisioned capacity
Roadmap / future features
- AWS continually evolves DynamoDB; roadmap timelines are not always publicly committed. Buyers should validate needed features against current documentation and service announcements.

02Why they buy

Competitive advantages observed in customer feedback and community discussions
- Some reviewers describe DynamoDB as a mature, reliable service that is commonly used in AWS-native architectures.
- Operational model reduces certain database administration activities for teams that align with its access-pattern-driven design.
Unique features and capabilities competitors implement differently
- Tight integration into AWS event-driven architectures (Streams + Lambda) is frequently cited as an advantage for serverless designs.
Differentiation from competitors based on reviews
- DynamoDB is often noted for operational characteristics and predictable performance for primary-key access patterns; competitors are preferred for query flexibility (MongoDB) or multi-API/multi-model patterns (Cosmos DB).
Areas where competitors clearly have advantages
- Cosmos DB: multi-API / query options and Azure ecosystem alignment.
- MongoDB Atlas: richer document querying and developer familiarity.
- Bigtable: suitability for very large-scale wide-column workloads and certain analytics integrations on GCP.

03Field reports

Customer Testimonials

Note: Review platforms aggregate many reviews; the items below summarize recurring themes observed in public reviews and community discussions.

Review platforms (G2, TrustRadius, Gartner Peer Insights) — common themes observed
- Positive themes frequently cited
  - Managed nature of the service reduces operational overhead for some customers
  - Performance at scale for key-value workloads is commonly reported
  - Integration with AWS services (Lambda/Streams/IAM) is frequently mentioned as a practical advantage
- Negative themes frequently cited
  - Steep learning curve for data modeling and index design
  - Cost surprises, particularly when access patterns are not modeled correctly or when using global replication and multiple indexes
  - Not a good fit for ad-hoc queries, joins, and relational reporting
Community commentary (summary of accessible public discussions)
- Some contributors note that for organizations that do not have very large-scale throughput requirements, a relational database may satisfy needs with less custom application-level logic and simpler data modeling.
- Other contributors recognize DynamoDB's engineering maturity and prevalence in AWS-native architectures.
- Several community posts highlight that single-table design can increase cognitive overhead for some teams and complicate operations and tooling (for example, visibility within the console).
- Pricing sentiment: multiple community threads express that DynamoDB can be more expensive than expected when compared with simpler databases, and that managed databases trade operational effort for higher service costs in certain scenarios.
Why customers chose DynamoDB over alternatives (recurring decision drivers)
- Fit for predictable access patterns with high throughput
- Managed service characteristics reduce certain operational responsibilities
- Native AWS integrations for event-driven/serverless architectures
Why some customers leave or avoid DynamoDB (common churn/avoidance reasons)
- Requirement for relational querying, joins, complex filters, and flexible analytics
- Organizational difficulty adopting single-table/denormalized modeling
- Cloud/provider lock-in concerns when multi-cloud portability is a priority
- Cost unpredictability if access patterns are not carefully managed

Genesys case study (AWS-published)

AWS describes Genesys using DynamoDB as part of a data tier and states a vendor-published availability figure.

Critical evaluation

The availability figure is presented in a vendor customer story; the measurement period, methodology, and what components are included/excluded are not fully transparent in the public case study. Treat the metric as vendor-published unless independently verified.

Venmo case study (AWS-published)

AWS reports that Venmo achieved a significant cost reduction and improved scalability by migrating a critical database to DynamoDB.

Critical evaluation

The reported cost reduction is a strong claim but appears in a vendor case study context; without detailed baseline configuration, workload mix, and cost model, it is difficult to generalize. It may reflect a specific before/after architecture and assumptions rather than typical outcomes.

What’s missing / harder to find

Detailed technical case studies that include implementation challenges, data modeling missteps, redesigns, and cost overruns are less common in official vendor materials. Community posts and threads sometimes call for more technical transparency and post-mortem detail.

04Best fit

Ideal Customer Profile

Company sizes
- Strongest fit often appears in:
  - Mid-market to large enterprises running significant production workloads on AWS
  - Startups that prioritize serverless speed and scale, provided their data model and access patterns are well understood
Industries and verticals
- Common usage across:
  - Fintech/payments (vendor case study: Venmo)
  - SaaS and cloud software
  - Customer experience/contact center platforms (vendor case study: Genesys)
  - Gaming, adtech, IoT, and high-volume telemetry
Roles and personas
- Decision makers
  - Head of Engineering, VP Engineering, Chief Architect, Platform/Infrastructure leaders
- End users
  - Backend engineers, serverless developers, SRE/platform teams
Pain points and challenges the product addresses
- Scaling operational workloads while reducing server management
- Handling spiky or unpredictable traffic (especially with on-demand)
- Building event-driven systems using Streams and Lambda patterns
Qualification criteria: what makes a GOOD fit
- Known and stable access patterns
- Need for high throughput and low latency
- AWS-first strategy and willingness to use AWS-native tooling
- Data model can be denormalized effectively
Deal disqualifiers: what makes a POOR fit
- Requirements for ad-hoc analytics queries, joins, or complex relational constraints
- Rapidly changing access patterns that would force repeated re-modeling
- Strong need for multi-cloud portability with minimal re-platforming
Real customer examples
- Genesys (AWS case study)
- Venmo (AWS case study)

05The pitch

What the product does (core value proposition in objective terms)

Amazon DynamoDB is a fully managed, serverless NoSQL database that targets low, predictable millisecond latency for key‑value and document access patterns at scale. It is positioned as an operational datastore for high‑throughput applications rather than as a general-purpose relational database. (Official positioning: “fast NoSQL key-value database.”)
Core building blocks include tables, partition keys/sort keys, secondary indexes (GSI/LSI), Streams for change data capture, TTL for expiry use cases (e.g., sessions), and optional in-memory acceleration via DAX.

Target market and market positioning

Target users are teams building cloud-native applications (often AWS-centric) that need:
- Very high request volume with low operational overhead
- Simple query patterns (primary key / range key) and denormalized data models
- Integration with AWS services (Lambda, API Gateway, Kinesis, S3, CloudWatch, IAM)
Market positioning: managed/serverless NoSQL with emphasis on operational characteristics, autoscaling options, and AWS ecosystem integration.

Get a comprehensive analysis of Amazon DynamoDB including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Workloads better served by relational databases
- For domains that are inherently relational (complex joins, reporting queries, transactional workflows that map naturally to SQL), a relational database (e.g., Aurora/Postgres) is often simpler to model and may be more cost-effective from a product-engineering perspective.
Early-stage teams without clear access patterns
- When application query patterns are still evolving and frequent schema and query changes are expected, DynamoDB modeling and index strategy can cause repeated rework.
Organizations with limited AWS experience
- If the team lacks practical AWS experience, DynamoDB’s API and operational model can still present a steep learning curve related to partitioning, hot keys, indexes, capacity, and cost controls.
Multi-cloud portability requirements
- When a database must move between clouds or on-premises with minimal changes, options such as MongoDB, Cassandra, or managed Postgres variants may reduce vendor lock-in.
Budget constraints with uncertain traffic
- When the organization cannot tolerate billing variability, fixed-price instances or systems with simpler cost envelopes may be preferable.
Need for flexible querying/search
- When rich filtering, full-text search, or analytics-like queries are first-class requirements, adding specialized systems (OpenSearch, Athena, Redshift) may be necessary and increase architectural complexity.
Data modeling constraints
- No native joins; relational queries typically require application-level joins or precomputed/materialized views.
Single-table design complexity
- Modeling for DynamoDB differs from relational design; teams report both successful outcomes and maintainability challenges.
Cost management
- Costs can rise unexpectedly with:
  - Hot partitions (poor partition key choice)
  - High write rates combined with multiple GSIs
  - Global Tables replication
  - Misconfigured provisioned capacity
Roadmap / future features
- AWS continually evolves DynamoDB; roadmap timelines are not always publicly committed. Buyers should validate needed features against current documentation and service announcements.

Note: Review platforms aggregate many reviews; the items below summarize recurring themes observed in public reviews and community discussions.

Review platforms (G2, TrustRadius, Gartner Peer Insights) — common themes observed
- Positive themes frequently cited
  - Managed nature of the service reduces operational overhead for some customers
  - Performance at scale for key-value workloads is commonly reported
  - Integration with AWS services (Lambda/Streams/IAM) is frequently mentioned as a practical advantage
- Negative themes frequently cited
  - Steep learning curve for data modeling and index design
  - Cost surprises, particularly when access patterns are not modeled correctly or when using global replication and multiple indexes
  - Not a good fit for ad-hoc queries, joins, and relational reporting
Community commentary (summary of accessible public discussions)
- Some contributors note that for organizations that do not have very large-scale throughput requirements, a relational database may satisfy needs with less custom application-level logic and simpler data modeling.
- Other contributors recognize DynamoDB's engineering maturity and prevalence in AWS-native architectures.
- Several community posts highlight that single-table design can increase cognitive overhead for some teams and complicate operations and tooling (for example, visibility within the console).
- Pricing sentiment: multiple community threads express that DynamoDB can be more expensive than expected when compared with simpler databases, and that managed databases trade operational effort for higher service costs in certain scenarios.
Why customers chose DynamoDB over alternatives (recurring decision drivers)
- Fit for predictable access patterns with high throughput
- Managed service characteristics reduce certain operational responsibilities
- Native AWS integrations for event-driven/serverless architectures
Why some customers leave or avoid DynamoDB (common churn/avoidance reasons)
- Requirement for relational querying, joins, complex filters, and flexible analytics
- Organizational difficulty adopting single-table/denormalized modeling
- Cloud/provider lock-in concerns when multi-cloud portability is a priority
- Cost unpredictability if access patterns are not carefully managed