DynamoDB Pricing Explained (2026): The Math Before You Lock Into AWS

The Time I Priced a Database I Never Shipped

Back when I was deep in Bitly-clone land building Clickly in 2023, I had this recurring fantasy. I’d hit ten million clicks a day, my little URL shortener would need “web scale,” and I’d stroke my chin and reach for something serious. Something the big boys use. Something like DynamoDB.

So one night, instead of getting a single paying user, I sat down and tried to price it out. Reader, I gave up around 1 AM with fourteen browser tabs open and a spreadsheet that made no sense. That’s the thing about DynamoDB pricing — it’s not expensive, exactly. It’s illegible. The pricing is built for people who already know their access patterns down to the kilobyte, and I was a broke engineer guessing.

Six months later I moved Clickly’s whole thing to plain PostgreSQL on Neon and never thought about capacity units again. But I did learn how DynamoDB pricing actually works. So let me save you the fourteen tabs.

---

What You’re Actually Paying For

DynamoDB is AWS’s serverless NoSQL key-value store. Unlike a normal database where you rent a box with some CPU and RAM, here you don’t pay for a server at all. You pay for four things:

1. Reads — every time you fetch data.
2. Writes — every time you put data in.
3. Storage — how much data sits there, per GB.
4. Everything else — backups, streams, global tables, and data leaving AWS.

That first pair is where the whole mental model lives, and it’s where people get burned. Throughput isn’t measured in “requests.” It’s measured in capacity units, and there are two flavors of how you buy them.

---

Mode 1: On-Demand (Pay Per Request)

This is the one you’ll start with, because it needs zero configuration. You just use the table and AWS bills you for what you touched. The units:

• A Write Request Unit (WRU) = one write of an item up to 1 KB. Write a 1.5 KB item? That’s 2 WRUs. A 5 KB item? 5 WRUs.
• A Read Request Unit (RRU) = one strongly consistent read of an item up to 4 KB. Eventually-consistent reads cost half. Transactional reads cost double.

Here’s the 2026 pricing in us-east-1, and note this — AWS cut on-demand throughput prices by 50% back in November 2024, so if you’re reading an older guide quoting $1.25 per million writes, it’s stale:

What	Price (us-east-1)
Write request units	$0.625 per million
Read units (strongly consistent)	$0.125 per million
Read units (eventually consistent)	$0.0625 per million
Transactional writes	$1.25 per million
Transactional reads	$0.25 per million

On paper, that looks cheap. A million writes for the price of a coffee? Sold. And for spiky, unpredictable traffic — the exact situation a new SaaS is in — on-demand genuinely is the sane default. You’re not paying for idle capacity at 3 AM when nobody’s using your app.

The catch is that “a million writes” evaporates faster than you think once your items are bigger than 1 KB, and once you add indexes. More on that below, because that’s the part that actually matters.

---

Mode 2: Provisioned Capacity (Reserve It Upfront)

The older model. Here you tell AWS “I want 100 write units and 200 read units per second, always,” and you pay for that reserved capacity by the hour whether you use it or not. The 2026 rates in the cheap regions:

• WCU: $0.00065 per unit-hour
• RCU: $0.00013 per unit-hour

That sounds like nonsense numbers, so let’s make it real. 100 WCUs running 24/7 for a month is roughly 100 × 0.00065 × 730 hours ≈ $47/month. Add auto-scaling so it flexes with load, or buy reserved capacity (a one-year commitment) for a steep discount, and provisioned becomes cheaper than on-demand once your traffic is steady and predictable.

That’s the whole trade: on-demand for spiky/unknown, provisioned for steady/known. For a solopreneur with no users yet, you have no idea what your traffic looks like, so you’ll live on on-demand — which is fine, until you meet the gotchas.

---

Storage, the Free Tier, and the Bill You Forget

Storage is the honest part. $0.25 per GB per month after the first 25 GB, which are free. Twenty-five gigabytes of key-value data is enormous for a starting SaaS — you’ll be nowhere near it for a long time. There’s also a cheaper “Standard-Infrequent Access” table class if most of your data is cold, but don’t bother optimizing that until you have data worth optimizing.

The free tier is genuinely generous and, unusually for AWS, permanent: 25 GB of storage, plus 25 WCUs and 25 RCUs of provisioned capacity, free every month, forever, on every account. One catch that trips people up — that 25 WCU / 25 RCU allowance only applies to provisioned mode. If you spin up a table in on-demand mode, you’re billed per request from the very first write. Small thing, but it’s exactly the kind of footnote that turns a “free” prototype into a surprise line item.

---

The Hidden Costs Nobody Puts on the Landing Page

Here’s where I actually earn your time. The sticker prices above are not what wrecks people. These are.

Global Secondary Indexes double (or triple) your writes

This is the big one. DynamoDB only lets you query efficiently on your primary key. Want to look data up a different way — say, “all orders for this customer” when your key is order ID? You add a Global Secondary Index (GSI).

The problem: a GSI is a full copy of your data, maintained live. Every write to your table also writes to every GSI, and you pay WRUs for each one. One GSI means every write is billed twice. Three GSIs and you’re paying four times for a single logical write — the base table plus three index updates. People model their data with five indexes because it’s convenient, then stare at a bill that’s 4–5x their estimate and can’t figure out why. That’s why.

Postgres, by comparison, gives you as many indexes as you want and just… includes them. You add a CREATE INDEX, and it costs you nothing beyond a little disk and slightly slower writes. No per-index billing meter running.

Hot partitions throttle you at the worst time

DynamoDB spreads your data across partitions based on your key. If your access pattern is lopsided — everyone hammering one popular item, or a key like “today’s date” that funnels all writes to one partition — you get a hot partition. On-demand will throttle those requests, and to avoid throttling you end up over-provisioning capacity you don’t need across the whole table. It’s a design tax that has nothing to do with total volume and everything to do with picking the wrong key on day one, when you knew the least.

Egress, the AWS classic

Data leaving AWS to the internet isn’t free. You get 100 GB a month free across all services, then it’s roughly $0.09 per GB in us-east-1. Traffic within the same AWS region is free, so if your whole stack lives in AWS this may never bite you — but the moment you’re serving data out to users or another cloud, the meter’s running. It’s the same egress tax that makes S3 quietly expensive too, and it’s easy to forget until Cost Explorer shows you a line you didn’t budget for. (When that day comes, here’s how to actually read that dashboard, and what a full SaaS actually costs per month.)

---

When DynamoDB Is Genuinely the Right Call

I’m not here to trash it. DynamoDB is a phenomenal piece of engineering, and there are real reasons the big platforms lean on it:

• Massive, predictable-shape scale. Single-digit millisecond reads at millions of requests per second, and it does not flinch. This is its home turf.
• You’re already all-in on AWS. If your Lambda functions, your queues, your everything already lives in AWS, DynamoDB’s tight integration and zero same-region egress are real advantages.
• Truly serverless ops. No instances to patch, no failover to configure, no “the database is at 90% CPU” pages at 2 AM. It just runs.

If you’re building something that genuinely needs that — an ad-tech firehose, a global gaming leaderboard, IoT ingestion — DynamoDB earns its keep and its price is fair. The other MongoDB-shaped NoSQL options aren’t automatically cheaper either; the cost model is just the cost of the category. (If you’re choosing between the two, DynamoDB vs MongoDB breaks down the data-model and lock-in trade-offs.)

But be honest about whether that’s you.

---

The Broken-Engineer Verdict

For 99% of founders reading this: DynamoDB is a premature optimization wearing an enterprise badge.

Here’s my problem with reaching for it early. It’s not the price — the price is fine, even cheap at small scale. It’s three other things.

One, you have to know your access patterns upfront. DynamoDB makes you design your keys and indexes around the exact queries you’ll run before you have users telling you what queries you need. That’s backwards for a product still finding its shape. With Postgres you just write a WHERE clause and figure it out as you go.

Two, the pricing is a cognitive tax. Every feature becomes a capacity-unit calculation. WRUs, RRUs, item sizes, GSI amplification, hot partitions — you spend brain cycles on the meter instead of the product. I did this to myself with Clickly and shipped nothing. The whole rabbit hole of over-engineering a database is a hole I dug personally, and DynamoDB was one of its deepest tunnels.

Three — and this is the big one — it locks you into AWS. DynamoDB’s query model is nothing like SQL. Once your app is built around it, leaving means a rewrite, not a migration. Postgres runs everywhere: Neon, Supabase, RDS, a $5 VPS, your laptop. You are never anyone’s hostage.

So here’s what I actually do, and what I’d tell my 1 AM self: use Postgres on Neon. It’s free until you have real traffic, it does relational data, JSON, full-text search, and vectors, and you don’t need a degree in capacity planning to add a feature. If you’re weighing where to run it, I compared Neon vs Supabase vs Vercel Postgres, and if you’re still stuck on the SQL engine itself, Postgres vs MySQL settles that in about two minutes. Postgres for ~99% of you. Full stop.

The day you genuinely outgrow it — millions of requests a second, a workload shaped exactly like DynamoDB’s sweet spot — you’ll have the revenue to hire someone who loves capacity units. Until then, every hour you spend pricing WRUs is an hour you’re not spending on the only thing that matters, which is getting someone to pay you.

Don’t price the database you’ll never ship. I already did that for both of us.

This is the Broken Engineer Guide — I over-engineer everything, fail at business, and hand you the receipts so you don’t have to. Go build something, and keep it on Postgres.