AWS NoSQL: A Complete Guide to Amazon’s Purpose-Built Database Portfolio
CTOs, VPs of Engineering, cloud architects, and platform teams choosing a managed NoSQL database on AWS. AWS does not offer one NoSQL database. It offers a portfolio of purpose-built ones, each tuned for a different data shape and access pattern. DynamoDB handles key-value and document workloads at limitless scale. DocumentDB covers JSON documents with MongoDB compatibility. ElastiCache and MemoryDB live in memory for microsecond speed. Keyspaces runs Cassandra workloads, and Neptune handles graphs. Timestream handles time-series data. The skill is not picking the trendiest service; it is matching the service to how your application actually reads and writes. This guide walks the full portfolio, the selection logic, the cost models, and the design habits that keep an aws no sql deployment fast and affordable. Ask a roomful of engineers which AWS database is the NoSQL one, and you will get several different answers. They are all correct. AWS deliberately rejected the idea of a single, do-everything database in favor of a portfolio of purpose-built services. Each is optimized for a specific data model and workload, and choosing well among them is one of the more consequential decisions an architect makes.
The scale these services reach is genuinely large. DynamoDB alone is built to handle more than 20 million requests per second and up to 10 trillion requests a day, with consistent single-digit-millisecond latency. That kind of headroom is why companies like Snapchat lean on NoSQL on AWS to move billions of messages daily. But raw capacity is only useful when it is pointed at the right problem.
This guide is a practical map of the AWS NoSQL landscape. We will tour each managed service, explain when it earns its place, look at how AWS charges for them, and cover the design and cost habits that separate a healthy deployment from an expensive one. The aim is to help you choose deliberately rather than by reputation.
What “NoSQL on AWS” Really Means
NoSQL stands for non-relational, and on AWS it really means purpose-built. Rather than forcing every workload into rows and columns, AWS provides databases designed for specific data models: key-value, document, in-memory, wide-column, graph, and time-series. Each one stores data in a flexible schema that scales easily for modern applications.
The practical advantage is twofold. First, you stop paying the performance tax of using the wrong tool, because each service is engineered for its job. Second, AWS manages the heavy lifting. Provisioning, patching, replication, and scaling are handled for you, and several of the services are fully serverless, so you never pay for capacity you do not use. That combination of fit and managed operations is the core appeal of going NoSQL on AWS.
It is worth being clear about what you give up in exchange. Purpose-built means each service is excellent at its job and deliberately limited outside it. A graph database is not where you cache sessions, and a key-value store is not where you run ad-hoc analytical queries. The portfolio approach asks you to understand your workload well enough to route it correctly. That is a small price for the performance and operational simplicity you gain, but it is a real shift in how teams think about data.
The AWS NoSQL Portfolio, Service by Service
Here is the current lineup of managed NoSQL services, organized by the data model each one serves. Think of them less as competitors and more as specialized tools in one toolbox.
Amazon DynamoDB — key-value and document
DynamoDB is the flagship and the one most teams reach for first. It is a serverless, fully managed key-value and document database that delivers consistent single-digit-millisecond performance at virtually any scale. It supports ACID transactions, encryption by default, in-memory acceleration through DAX, and automatic replication across three Availability Zones. With global tables, you can replicate data across regions for low-latency access worldwide. It suits scalable web and mobile apps, shopping carts, gaming, and any workload with high, spiky throughput.
The migration stories are instructive. McAfee, for instance, moved from Microsoft SQL Server to DynamoDB to power a next-generation messaging platform at scale. The catch with DynamoDB is that it rewards careful design. You model the table around your queries rather than around normalized entities, and a weak partition key will throttle even the most generous capacity. Get the key right, and the scaling is effectively unlimited.
Amazon DocumentDB — JSON documents, MongoDB-compatible
DocumentDB is a fully managed native JSON document database that is compatible with MongoDB APIs and drivers. It separates compute from storage for independent scaling, supports up to 15 read replicas, and replicates across three Availability Zones for durability. Because it speaks the MongoDB API, teams can move existing MongoDB workloads with minimal code changes. It shines for content management systems, product catalogs, and user profiles where data structures evolve and flexible querying matters.
Scale is not a concern here either. Amazon’s own fulfillment organization chose DocumentDB to power its inventory authority platform, a demanding, mission-critical workload. AWS also provides a compatibility tool that assesses how cleanly a MongoDB application will move over, plus free use of the AWS Database Migration Service to ease the transition. For teams already invested in MongoDB, that lowers the cost of going managed considerably.
Amazon ElastiCache and MemoryDB — in-memory speed
When microseconds matter, the data lives in memory. ElastiCache is a fully managed, Redis- and Memcached-compatible cache and data store, ideal for caching, session stores, and real-time analytics. MemoryDB goes a step further: it is a durable, in-memory database that delivers microsecond reads and single-digit-millisecond writes while persisting data, so it can serve as a primary store rather than just a cache. Teams reach for these to slash latency on the hottest paths in an application.
The impact can be dramatic. Groupon uses ElastiCache to curate deals at speed, and real-time bidding platforms have cut latency several times over while sustaining very high uptime by moving hot data into memory. These services suit gaming leaderboards, ad targeting, ride-hailing, and any workload that must answer in microseconds across enormous request volumes.
Amazon Keyspaces — wide-column, Cassandra-compatible
Keyspaces is a serverless, fully managed wide-column database compatible with Apache Cassandra. It supports the Cassandra Query Language, so existing Cassandra applications, code, and tools carry over with little friction. It scales for large, write-heavy, globally distributed workloads and offers autoscaling with on-demand or provisioned capacity. Typical fits include time-series data, clickstream tracking, IoT event processing, and high-volume activity logging.
The serverless model is the real draw for teams burned by operating their own Cassandra rings. There are no nodes to size, no clusters to rebalance, and no compaction to babysit. You define your tables and let the service handle the rest, which removes a class of operational toil that has historically made Cassandra powerful but demanding to run.
Amazon Neptune — graph
Neptune is a fully managed graph database built for highly connected data. It stores entities as nodes and relationships as edges, and it can query billions of relationships in seconds. Neptune supports both the Property Graph model and RDF, with the Gremlin, openCypher, and SPARQL query languages. It is the right choice for recommendation engines, knowledge graphs, fraud detection, and network security. Security platform Wiz, for example, uses a Neptune graph to weave together interconnected risk factors in seconds.
Graph databases have also become more relevant in the AI era. Knowledge graphs give large language models structured, trustworthy context, and AWS now documents building GraphRAG applications that pair Amazon Bedrock with Neptune. If your roadmap includes generative AI grounded in your own domain data, a graph layer is increasingly part of the architecture rather than a niche concern.
Amazon Timestream — time-series
Timestream is a purpose-built, serverless time-series database. Time-series data is ordered by timestamp rather than by value or ID, which makes general-purpose databases awkward and expensive for it. Timestream handles ingestion and querying of trillions of events efficiently, with tiered storage that moves older data to cheaper tiers automatically. It fits industrial telemetry, DevOps and application metrics, and Internet-of-Things workloads.
That automatic tiering is what makes Timestream economical at scale. Recent, frequently queried data stays in a fast memory tier, while older data ages into low-cost storage without manual intervention. For workloads that generate enormous volumes of metrics but query mostly recent windows, this design keeps both performance high and cost predictable.
A note on Amazon QLDB
You may still see Amazon QLDB, the ledger database, mentioned in older guides. It is worth knowing that AWS ended support for QLDB on July 31, 2025. For ledger-style use cases that need an immutable, verifiable history, AWS now points customers to Amazon Aurora PostgreSQL with appropriate extensions. If a tutorial recommends QLDB, treat it as out of date, and plan around a supported alternative instead.
How to Choose the Right AWS NoSQL Service
With so many options, the choice can feel paralyzing. It becomes straightforward once you start from the data, not the service. Ask how your application reads and writes, then let the answer point to a model.
Need ultra-low-latency lookups by key at huge scale? DynamoDB is the default answer.
Working with nested JSON documents or migrating from MongoDB? DocumentDB fits.
Chasing microsecond response times for hot data or sessions? ElastiCache, or MemoryDB when you also need durability.
Running Cassandra workloads or heavy, distributed writes? Keyspaces is the managed path.
Modeling relationships as the core of the product? Neptune and its graph engine win.
Storing telemetry or metrics ordered by time? Timestream is built for exactly that.
Two further factors matter beyond the data model. Consider how deeply each option integrates with the rest of your AWS stack, since pairings like DynamoDB with Lambda enable clean serverless designs. And consider your team’s existing skills, because a service that matches what your engineers already know reduces both risk and ramp-up time.
DynamoDB or DocumentDB? The most common dilemma
Because both store document-style data, teams frequently agonize over these two. A useful rule of thumb settles most cases. Choose DynamoDB when you need extreme scale and predictable low latency for well-defined access patterns, especially key-based lookups. Choose DocumentDB when your data is genuinely document-shaped, with nested fields and arrays, and you need rich querying, secondary indexes, and aggregation, or when you are migrating from MongoDB. In short, DynamoDB optimizes for scale and speed on known patterns; DocumentDB optimizes for flexible querying of complex documents.
Migrating to AWS NoSQL
For most enterprises, AWS NoSQL is not a greenfield decision. It is a migration from a self-managed database or a legacy relational system. The good news is that AWS has paved this path well, and the managed services remove most of the operational burden once you arrive.
The typical pattern is a two-phase move: a full load of existing data, followed by ongoing replication until cutover, usually orchestrated with the AWS Database Migration Service. DocumentDB makes this especially smooth for MongoDB users, offering a compatibility tool to flag any code that needs attention and free use of the migration service. Keyspaces lets Cassandra workloads carry over with their existing CQL code and tools. The migrations that go badly are almost always the ones that treat the new database like the old one. The migrations that go well start by rethinking the data model to suit the target service.
Speed of delivery is a real benefit once you commit. PricewaterhouseCoopers, for example, built and launched its Check-In product on Keyspaces in roughly three months, precisely because the managed service removed the infrastructure work. That kind of velocity is the practical payoff of choosing managed NoSQL over running your own clusters.
Understanding Cost and Capacity Models
NoSQL on AWS can be remarkably cost-effective, but only when you understand how each service charges. Getting the capacity model wrong is one of the most common ways teams overspend.
Several services, including DynamoDB and Keyspaces, offer two capacity modes. On-demand pricing charges per request and requires no capacity planning, which is ideal for unpredictable or spiky traffic. Provisioned capacity reserves a set throughput at a lower unit cost, which rewards steady, predictable workloads. Choosing the wrong mode can multiply your bill, so match the mode to your traffic shape and revisit the choice as patterns change.
Serverless options add another lever. Because serverless services scale to actual usage, you avoid paying for idle, over-provisioned capacity. The flip side is that costs track usage closely, so a runaway query pattern shows up directly on the invoice. Treat database cost as a first-class engineering metric. Instrument spend per workload, set billing alarms, and review cost with the same regularity you give to latency and uptime.
Designing for Scale and Reliability
The managed services do a great deal for you, but architecture still decides whether a deployment thrives. A few habits matter more than the rest.
Model around access patterns
This is the single biggest shift from relational thinking. With DynamoDB especially, you design the table around the queries your application runs most, not around a normalized entity diagram. Denormalizing data to avoid expensive cross-partition reads is often the right call. Know your access patterns before you finalize the schema, because changing a primary key after launch is painful.
Build in availability from the start
AWS NoSQL services replicate across multiple Availability Zones automatically, which protects you from the loss of any single data center. For global or mission-critical applications, go further. DynamoDB global tables and multi-region replication put data close to users and provide a strong disaster-recovery posture. Decide on your availability and recovery targets early, since they shape both the design and the cost.
Secure it by default
Security is not an afterthought on AWS, and the NoSQL services make it easy to do well. Encryption at rest is on by default across the portfolio, and tight integration with AWS Identity and Access Management lets you enforce least-privilege access at a fine grain. Combine that with VPC isolation and audit logging through CloudTrail, and you get an enterprise-grade security baseline without building it yourself.
Polyglot Persistence: Use More Than One
Here is a point teams often miss: you rarely pick just one. Mature architectures use polyglot persistence, pairing several databases so each handles what it does best. The purpose-built portfolio is designed for exactly this.
Consider a typical e-commerce platform. It might store product catalogs and user profiles in DocumentDB for flexible, semi-structured data, serve fast catalog browsing through DynamoDB for predictable low latency, cache the hottest pages in ElastiCache, and use a relational engine like Aurora for orders and inventory where transactions matter. Each service does one job well, and the application stitches them together. This is not over-engineering; it is using the right tool for each pattern, which is the whole philosophy behind AWS NoSQL. The one caution is operational: every additional data store is another thing to monitor, secure, and reason about, so add services because a workload genuinely needs them, not because they are available.
Common Pitfalls to Avoid
Most AWS NoSQL regrets trace back to a short list of avoidable mistakes.
Forcing relational query patterns, such as complex joins, onto a key-value model that punishes them.
Choosing a poor partition or primary key, which concentrates load and quietly caps throughput.
Picking the wrong capacity mode, then overpaying for provisioned throughput on a spiky workload.
Ignoring cost instrumentation until a multi-region rollout produces a surprising invoice.
Building on a retired or deprecated service because a stale tutorial recommended it.
Each of these is a decision the platform forces you to make explicitly. The services are honest about their trade-offs; the trouble starts when teams skip the trade-off and hope for the best.
The Bottom Line
AWS NoSQL is not a single product to learn but a portfolio to navigate. Its strength is precisely that breadth: a purpose-built database for nearly every data shape, all fully managed and ready to scale. The work, and the value, lies in choosing well. Start from how your application reads and writes, match that pattern to the right service, pick the capacity model that fits your traffic, and design around access patterns from day one. Lean on the managed availability and security, watch your cost like a metric that matters, and do not be afraid to combine services. Do that, and the AWS portfolio will scale with your business rather than constrain it.
Work With PracticalLogix
Choosing among AWS NoSQL services, or trying to tame a deployment that has outgrown its design? Our cloud teams help enterprises architect, migrate, and optimize data platforms on AWS. Here is how we can help:
AWS database architecture assessment — evaluate your workloads and map each to the right purpose-built service.
NoSQL migration and modernization — move from self-managed databases to managed AWS services without downtime surprises.
Cost and performance optimization — tune capacity modes, partitioning, and replication to balance speed against spend.
Talk to an engineer — book a working session with a PracticalLogix cloud architect to pressure-test your design.
Reach the team at practicallogix.com/contact to start the conversation.