At 11:48 PM Pacific time on October 19, 2025, a piece of automation inside AWS left an empty DNS record for one web address: dynamodb.us-east-1.amazonaws.com. DNS works like the internet's phone book. It turns a name into the number a computer actually dials. With that entry blank, any program trying to reach DynamoDB in Amazon's Northern Virginia region simply couldn't find it.
What followed was one of the most visible cloud outages in years. Snapchat, Fortnite, and a number of banks were among the services people reported as down or slow on October 20. AWS later traced the trouble to a race condition, where two automated processes step on each other's work, inside the system that manages DNS records for DynamoDB.
The outage made headlines. Far less attention went to what the same service did three months earlier. During Prime Day 2025, Amazon's own systems made tens of trillions of calls to DynamoDB, and traffic peaked at 151 million requests per second, according to AWS. A database that handles that kind of load, and that so many other services quietly lean on, is worth understanding properly.
This guide covers what Amazon DynamoDB is, how it grows with your traffic, where it gets awkward, and how to tell whether it belongs in your app. You don't need a database background. Technical terms come with a short explanation.
What DynamoDB is, in everyday terms
DynamoDB is a database that Amazon runs for you. You create a table, put data in, and read it back, without choosing server sizes or installing patches. AWS describes it as serverless. There are still servers, of course. You just never manage them.
It is a NoSQL database, a label for any database that doesn't force data into the strict rows and columns of a traditional SQL system such as MySQL or PostgreSQL. It stores data as key-value pairs and as documents, bundles of related fields that look like a JSON file.
A few words come up constantly:
◆ A table is a collection of related data, such as all your customers or all your orders.
◆ An item is one record in that table, like a single customer.
◆ An attribute is one detail on an item, such as an email address or a signup date.
◆ The partition key is the main label DynamoDB uses to decide where an item is stored and how to find it quickly.
◆ The sort key is an optional second label that keeps related items in order, for example every order from one customer arranged by date.
Think of a warehouse full of filing cabinets. The partition key tells the clerk which cabinet to open, and the sort key says which folder. With both, the clerk finds your file almost instantly, however big the warehouse gets. Without them, the clerk walks every aisle. DynamoDB calls that walk a Scan, and on a big table it is slow and costly.
Where it came from
The idea started inside Amazon's retail business. In 2007, Amazon engineers published a research paper on Dynamo, an internal key-value store built so that shopping carts kept working even when parts of the system failed. On January 18, 2012, AWS launched Amazon DynamoDB as a public service. A 2022 paper by the DynamoDB team, presented at the USENIX Annual Technical Conference, describes Dynamo as its predecessor and explains how the design changed over a decade.
Because it is an AWS database service, DynamoDB connects closely with the rest of Amazon's cloud. It works with Lambda, which runs small pieces of code on demand, and with S3 for storing files. That tight fit is a big reason startups on AWS reach for it early.
The numbers behind it
Figures compiled from the sources named in each row.
Between 2021 and 2025, Amazon's peak Prime Day load on DynamoDB grew roughly 69%, from one company's internal use alone.
The wider market is harder to pin down. Research firms agree that the NoSQL database market is growing, but they disagree sharply on how fast. IMARC Group valued the global NoSQL market at USD 11.9 billion in 2024 and expects it to reach USD 81.9 billion by 2033. SkyQuest started from almost the same 2024 figure, USD 11.95 billion, yet projects USD 125.86 billion by 2033. TechSci Research valued the market at USD 10.23 billion in 2023 and forecasts USD 24.21 billion by 2029, which works out to about 15% growth a year, compared with the 24% to 30% the other two firms expect. Each firm defines the market its own way, so treat these as a sense of direction, not a precise forecast.
In the Stack Overflow Developer Survey 2025, DynamoDB ranked tenth among databases by usage, while PostgreSQL led with 55.6%. AWS itself was used by 43.3% of respondents, so many developers already work close to DynamoDB.
How DynamoDB grows with your traffic
Behind every table, DynamoDB splits your data into chunks called partitions. A partition is a slice of storage on Amazon's machines. When you save an item, DynamoDB feeds its partition key through a hash function, a bit of math that turns any value into a number that looks random, and uses that number to choose a partition.
This spreading is the heart of DynamoDB scaling. When your data grows or your traffic climbs, DynamoDB splits busy partitions in two and moves the halves onto separate machines. You don't schedule it, and the table keeps answering requests while it happens.
Each partition still has a ceiling, though. AWS documents that every partition is designed to deliver up to 3,000 read units and 1,000 write units per second. Those units need a quick explanation:
◆ One read unit covers one strongly consistent read per second of an item up to 4 KB in size, or two eventually consistent reads of the same size.
◆ One write unit covers one write per second of an item up to 1 KB.
A strongly consistent read always returns the latest saved version of an item. An eventually consistent read might return a version that is a fraction of a second old, and it costs half as much. Bigger items use more units. AWS gives the example of a 20 KB item: each strongly consistent read of it uses 5 read units, so a single partition can serve about 600 of those reads per second before it hits its limit.
DynamoDB also has a feature called adaptive capacity. When one partition gets far more traffic than its neighbors, DynamoDB shifts capacity toward it and can move very popular items onto their own partition. It still can't make a single key faster than one partition allows, and that is where most real-world trouble starts.
On-demand or provisioned: choosing a capacity mode
DynamoDB offers two ways to pay for reads and writes, and the choice shapes how your table handles traffic jumps.
With on-demand mode, you pay for each request and skip planning altogether. AWS documents that a new on-demand table can handle up to 4,000 writes and 12,000 reads per second straight away. From there, it instantly accommodates up to double the previous peak traffic the table has seen. A table that peaked at 50,000 reads per second can jump to 100,000, and once it sustains that, 200,000 becomes possible.
The catch: if traffic climbs past double the previous peak within 30 minutes, requests can get throttled, meaning DynamoDB rejects some and asks your app to retry. For launches you can see coming, AWS lets you pre-warm a table by setting what it calls warm throughput ahead of time. Since early 2024, on-demand tables also accept an optional maximum throughput setting, which caps how far a table can scale and protects you from a surprise bill caused by a bug or a traffic flood.
With provisioned mode, you tell DynamoDB how many read and write units you want per second, and you pay for that capacity by the hour whether you use it or not. Auto scaling can raise and lower the numbers within limits you set, but it reacts after traffic changes, so a sudden spike can arrive before the extra capacity does.
Pricing shifted in favor of on-demand in late 2024. Effective November 1, 2024, AWS cut on-demand throughput prices by 50%. In its announcement, AWS said most workloads running in provisioned mode would now cost less in on-demand mode, and it called on-demand the default and recommended mode for most DynamoDB workloads. The same change lowered the price of writes copied between Regions by 67% for on-demand tables and 33% for provisioned ones. For founders, it changed how this AWS database service charges for growth.
Where DynamoDB earns its place
DynamoDB shines when you know in advance exactly how your app will look up its data. Here are situations where teams commonly use it:
◆ Shopping carts and orders fit naturally, since every lookup starts from a customer ID or an order ID. This is the problem the original Dynamo was built to solve.
◆ User profiles and login sessions work well because each request asks for one user's data. Sessions can carry an expiry time so DynamoDB removes them later on its own.
◆ Games store player state and inventories keyed by player ID, which keeps reads fast on a busy launch day.
◆ Sensor readings can be stored under a device ID with a timestamp as the sort key, making "the last hour for this device" a quick query.
◆ Serverless backends built on Lambda pair well with on-demand pricing, since both charge only when something happens.
◆ AI applications often keep chat history and agent state keyed by conversation ID, paired with a separate vector service, since DynamoDB doesn't search by meaning on its own.
The common thread: the app asks for data by a known key. When questions get open-ended, such as "which customers in Pune spent more than ₹10,000 last month and also returned an item," DynamoDB becomes much less comfortable.
How DynamoDB compares with other options
Here is how Amazon DynamoDB lines up against two popular alternatives.
A NoSQL database like DynamoDB trades query freedom for speed and predictable performance. PostgreSQL makes the opposite trade. Plenty of teams run both, using DynamoDB for high-traffic lookups and PostgreSQL for reporting, billing, and admin screens.
When the data gets messy: the technical side
Feature lists make every database look tidy. Here is how DynamoDB behaves when real apps get messy.
Data gaps
DynamoDB doesn't enforce a schema beyond the key fields. One item can have twelve attributes and the next can have three. That helps when your product changes quickly, but your code must handle missing fields, such as an older item lacking the "phone number" field a new feature expects.
Global secondary indexes, usually shortened to GSIs, create gaps of their own. A GSI is a second copy of your data organized around a different key, so you can look items up another way, such as finding orders by status instead of by customer. GSIs are updated in the background and support only eventually consistent reads. If you write an item and query a GSI a moment later, the new item might not appear yet. On the plus side, a GSI only includes items that have the index key, so you can build small indexes of just the items you care about, such as unpaid invoices.
Expired data can linger too. DynamoDB's Time to Live feature, or TTL, deletes items after a timestamp you set, but it works on a best-effort basis and removal can lag behind the expiry time. Until an expired item is actually deleted, it still shows up in reads and queries. If your logic depends on exact expiry, filter on the timestamp in your own code.
One more gap catches beginners. A single Query or Scan returns at most 1 MB of data. If there is more, the response includes a marker called LastEvaluatedKey, and your code must call again from that point. Forget to loop, and your app silently works with partial results.
Conflicting signals
Metrics can disagree with what users experience. Your monitoring may show a table using 30% of its capacity while users see errors. Both are true. The table-wide average hides one overloaded partition. CloudWatch Contributor Insights, a monitoring add-on, shows which keys get the most traffic.
Data itself can conflict when you run in several Regions. A Region is one of Amazon's geographic data center groups, such as Mumbai. Global tables copy your table across Regions for fast local access. By default they use multi-Region eventual consistency, and when two Regions update the same item at nearly the same moment, the write with the later timestamp wins. AWS calls this last writer wins. The losing update disappears without an error.
For data where that is unacceptable, such as account balances or stock counts, AWS made multi-Region strong consistency generally available on June 30, 2025. In that mode, a write confirmed in one Region is immediately readable from the others, and AWS says it supports a recovery point objective of zero, meaning no confirmed data is lost in a Regional failure. At launch it was offered in a limited set of Regions, and because each write must be confirmed across Regions before it counts, writes take longer.
Survey data sends mixed signals as well. In the Stack Overflow Developer Survey 2025, 39.7% of developers who had used DynamoDB said they wanted to keep using it, compared with 65.5% for PostgreSQL. My reading, and it is only an interpretation since the survey doesn't ask why, is that DynamoDB's modeling style frustrates people who expect SQL habits to carry over.
Real-time decisions
Many apps must decide something the instant a request arrives. Should this ticket sale go through? Has this coupon been used?
Conditional writes let you say "save this only if a condition holds," such as "reduce stock by one only if stock is above zero." DynamoDB checks and writes in one step, so two buyers can't both grab the last seat at a concert.
Transactions go further. A single transaction can group up to 100 actions across tables in the same account and Region, with a combined size of up to 4 MB. Either every action succeeds or none of them do. If you pass a client token with the request, you can safely retry it for 10 minutes without applying it twice, which matters when a mobile connection drops halfway through a payment.
You also choose read consistency per request: strong for a wallet balance, eventual for a product description at half the cost.
DynamoDB Streams records every change to a table in order for each item and keeps those records for 24 hours. A Lambda function can react to each change, such as sending a confirmation email. If whatever reads the stream stays down longer than 24 hours, the older changes are gone.
Exceptions and edge cases
A few hard limits surprise people in production:
◆ An item can't be larger than 400 KB. Store images, PDFs, and long transcripts in S3 and keep only a link in DynamoDB.
◆ If a table has a local secondary index, all items sharing one partition key value are capped at 10 GB combined.
◆ A transaction can't touch the same item twice, and it can't reach across AWS accounts or Regions.
◆ TTL skips items whose expiry timestamp looks more than five years old, a safeguard AWS added so a badly formatted value doesn't wipe out data by accident.
◆ On-demand tables have default account-level quotas of 40,000 read units and 40,000 write units per table. You can request an increase through the Service Quotas console, but it's better done before a launch than during one.
◆ Filters in a Query or Scan apply after DynamoDB reads the data, so you pay for every item read, including the ones the filter throws away.
Behavior under pressure and at scale
When DynamoDB can't serve a request in time, it throttles: it returns an error that tells your app to slow down and try again. The official AWS SDKs retry automatically using exponential backoff, which means waiting a little longer after each failed attempt. Short bursts usually pass unnoticed. Long ones surface as errors your app must handle.
Indexes add pressure in a less obvious way. If a GSI can't keep up with incoming writes, DynamoDB throttles writes to the main table as well.
The doubling rule from on-demand mode matters a lot here. Say your app normally peaks at 5,000 writes per second, and a TV mention sends 40,000 in five minutes. That is eight times the old peak, far past the "double within 30 minutes" allowance, so some writes will be throttled while DynamoDB adds capacity. Pre-warming the table before a planned campaign avoids most of that. Good DynamoDB scaling comes down to this kind of planning more than any setting flipped mid-crisis.
Finally, DynamoDB is a Regional service. Within a Region, it keeps your data across multiple Availability Zones, which are separate data centers, so losing one building doesn't take your table down. Losing an entire Region's endpoint is another matter, as October 2025 showed. Reports from that day noted that some global tables features tied to the Northern Virginia Region were affected too. If your business can't tolerate a Regional outage, plan for a second Region early and test how your app fails over.
A practical guide to getting started
If DynamoDB looks like a fit, these steps help you avoid common early mistakes:
Step 1. Write down every way your app will read data before you design a single table.
Step 2. Pick a partition key with many distinct values that get used fairly evenly, such as user ID or order ID. Avoid keys like today's date or an order status, where everyone hits the same value at once.
Step 3. For keys you know will run hot, add a small random suffix when writing, such as splitting one tournament into ten sub-keys, and read from all ten when you need the full picture. Engineers call this write sharding.
Step 4. Start new tables in on-demand mode and set a maximum throughput so a runaway bug can't produce a runaway bill.
Step 5. Keep items small. Large files belong in S3, with a link stored in DynamoDB.
Step 6. Set alarms on throttled requests from day one and turn on Contributor Insights for your busiest tables.
Step 7. Pre-warm tables before planned launches, sales, or campaigns.
Step 8. Decide early whether you need one Region or several, because moving to multi-Region later means revisiting how you handle conflicting writes.
These habits form the basis of healthy DynamoDB scaling for small teams, long before traffic gets large.
When DynamoDB is the wrong choice
If your team mostly asks new questions of its data, such as building reports or exploring trends, DynamoDB will fight you. You can export tables to S3 for analysis, and AWS offers zero-ETL integrations with Amazon Redshift and Amazon OpenSearch Service, but those are extra moving parts.
Highly relational data with lots of connections between records, like an accounting ledger or a school's timetable, usually fits PostgreSQL better. If you need to run the same database on Google Cloud, Azure, or your own servers, DynamoDB isn't an option, since it exists only as an AWS database service. For a small internal tool with a few thousand records, a relational database is often simpler.
None of this makes DynamoDB a poor product. It's a specialist, best used where its strengths match your problem.
Final thoughts
DynamoDB asks for one thing up front: knowing how your app reads its data. Give it that, and it handles growth from a weekend side project up to Amazon's own Prime Day traffic. Skip that step, and you'll spend your time fighting hot keys.
The October 2025 outage is a fair reminder that no managed service removes the need to plan for failure. It also showed how many companies had built on Amazon DynamoDB in the first place. If you're weighing it for your next project, take the busiest screen in your app, write down exactly how it reads data, and try modeling it as a table with a partition key and a sort key. Within an afternoon, you'll know whether the fit is natural or forced.
