Amazon DynamoDB

1. Serverless zero-ops: no instances, no patches, no version upgrades Why it's real: there are no concepts of "primary/replica," "shard ops," or "version upgrades" — throughput and storage scale automatically; this is its hardest differentiator against every self-hosted/semi-managed database. Edge truth: the ops work didn't disappear, it changed shape — the DBA became a "capacity modeler + FinOps engineer": on-demand vs. provisioned, GSI projections, item-size rounding — every choice connects directly to the bill. If nobody on the team understands RCU/WCU billing, "zero ops" becomes "bill shock with no early warning."
2. Single-digit-millisecond latency independent of scale Why it's real: partitioned-hash architecture — GetItem/Query latency doesn't care whether the table is 1GB or 100TB (official docs wording: single-digit milliseconds); this is where the relational-database curve of "more data → deeper indexes → slower" simply doesn't exist. Edge truth: only holds for key-based access. Full-table Scans, cross-partition aggregations, and GSI backfills are linear-cost operations; strong reads cost 2x RCU; DAX can push reads to microseconds but only caches eventually consistent reads — ConsistentRead=True bypasses DAX entirely (configuring DAX then running everything strongly consistent = money down the drain).
3. Global Tables: genuinely multi-region, multi-write Why it's real: every region is readable and writable with local-latency writes worldwide; the natural solution for region-level DR and global read/write. Edge truth: see Deep-dive 6 — MREC's last-writer-wins silently drops updates; MRSC requires a fixed 3-region topology, no transactions, no TTL, and pays a cross-region quorum tax on write latency. What's multi-active is "access," not "consistency for free."
4. Streams + TTL + PITR, all out of the box Why it's real: CDC (Streams→Lambda), auto-expiry (TTL at zero storage cost), and 35-day second-level PITR are all first-party toggles — no need to assemble Debezium/backup scripts yourself. Edge truth: Streams retain only 24 hours with at most 2 consumers per shard — high-throughput CDC needs Kinesis Data Streams for DynamoDB instead; TTL deletion is "best effort within 48 hours," not punctual expiry (if expired items must be invisible on time, the application layer still has to filter); PITR restore only creates a new table.
5. Vector search (GA 2026-08): ANN inside a KV store Why it's real: up to 5 vector indexes per table, 4096 dimensions, TopK 100 — "metadata filtering + vector recall" in one database for RAG scenarios. Edge truth: base tables over 600GB require an allowlist (details to-be-verified); don't treat it as a dedicated vector database — large-scale ANN performance and ecosystem depth (LangChain integration) await production validation. This is "vector search as a convenience," not "a vector database."

Deep-dive 1 (Storage/Performance): Partitions are the physical ceiling; hot keys are a design tax (domain: storage engine)

• Mechanism: items are distributed to internal partitions by partition-key hash; each partition has a hard cap of 3,000 RCU / 1,000 WCU 官方文档, identical for provisioned and on-demand; burst capacity borrows 300 seconds of unused allowance to absorb short spikes, adaptive capacity moves idle allowance to hot partitions (even isolating hot keys onto dedicated partitions).
• At the edge: no matter how much adaptive capacity can borrow, it can't borrow past the partition ceiling — a single key written at over 1,000 WCU/s is a death sentence, because automatic partition splitting looks at throughput, not key cardinality: one key can never span two partitions. Table-level CloudWatch shows "only 43% of capacity used" while requests get bounced with ProvisionedThroughputExceededException — DynamoDB's most classic incident scene. The only fix is write sharding (user#0…#N suffix scattering), at the cost of scatter-gather reads and application-layer merge sorting.
• What it means for selection: key design is DynamoDB's #1 productivity lever; the POC must be load-tested with real key distributions — uniform load tests are self-deception; turn on Contributor Insights and put "hot-key location" in the on-call runbook.
• Sources: official docs (burst/adaptive capacity); dev.to community analysis (2026-08); community skill docs (2026-09)

Deep-dive 2 (Cost): The RCU/WCU rounding tax and the "convenience tax" (domain: cost)

• Mechanism: writes are billed per 1KB rounded up to WCU, reads per 4KB rounded up to RCU; strong reads cost 2x; transactional writes cost 2x; writes that fail conditional expressions are still billed; on-demand unit price is several times that of fully-utilized provisioned (community wording: 5–7x).
• At the edge: a 1.1KB item is billed as 2KB — nested JSON, timestamps, and metadata make "just barely over" the norm, which a third-party blog calculated as a 67% hidden surcharge at 100 million writes/day; teams that "go live on on-demand and switch to provisioned later" only remembered to switch after the bill jumped from $11K to $39K/month (third-party blog case, vendor-neutral); a Scan for an admin dashboard: scanning 100 million items costs about $125 per full scan (third-party source) — every dashboard refresh burns cash.
• What it means for selection: bake "every KB is money" into schema reviews at item-design time; monitor conditional-write failure rates (failed writes = burning money for nothing); on-demand is only for "unpredictable" loads — if the monthly bill exceeds $100 and traffic is predictable, switch to provisioned + auto-scaling (community rule of thumb); never Scan for analytics — export to S3 and query with Athena.
• Sources: hackernoon third-party cost analysis; awslabs startup-advisor skill docs (2026-09); community consensus

Deep-dive 3 (Cost/Consistency): The GSI is a "second bill," and it only gives eventual consistency (domain: indexing)

• Mechanism: each GSI is billed independently — writing an item containing a GSI key attribute charges WCU once on the base table and once per GSI (ALL projection ≈ doubling write cost); GSIs have independent throughput quotas and independent throttling; GSI reads are always eventually consistent; LSIs can only be created at table-creation time, share the table's throughput, and cap at 10GB per partition-key value.
• At the edge: updating a GSI key attribute = deleting the old index entry + writing a new one, one update billed twice for GSI writes; a "just add an index to look up email" PR raised the monthly bill by $800 and write latency by 40% (Medium community case, 2025-10); 5 fully-projected GSIs = the write bill ×6; GSI backpressure can also slow base-table writes (writes must wait for index writes).
• What it means for selection: the GSI is part of schema design, not an "add an index" button at ops time; keep projections minimal (KEYS_ONLY/INCLUDE); sparse indexes (only giving some items a GSI key) are the standard cost-saving move; a second access pattern that needs strong consistency can only use an LSI — but the LSI must be planned at table-creation time.
• Sources: official docs; Medium community case (2025-10); community skill docs (2026-09)

Deep-dive 4 (Replication/CDC): Streams' 24-hour retention and 2-consumer ceiling (domain: replication & CDC)

• Mechanism: DynamoDB Streams push changes in shard order, retained for 24 hours; at most 2 consumers per shard; typically consumed via Lambda.
• At the edge: if a consumer falls behind for more than 24 hours, the data is permanently lost — there's no "replay from the beginning" second chance; a third consumer (audit + cache invalidation + search sync each wanting one) gets rejected outright, forcing a move to Kinesis Data Streams for DynamoDB (up to 1 year retention, 5+ consumers); 10,000 writes/second = 10,000 Lambda invocations/second, exploding both the Lambda concurrency quota and the invocation bill; a single poison record blocks retries for the entire shard.
• What it means for selection: Streams are a "trigger," not a "message queue"; with more than 2 downstream consumers or any replay need, go Kinesis first; Lambda consumers must be idempotent with a dead-letter queue — poison records must not block the shard.
• Sources: official docs; awslabs startup-advisor (2026-09); community skill docs (2026-09)

Deep-dive 5 (Modeling): Single-table design — moving joins out of the database and into your head (domain: modeling/migration)

• Mechanism: DynamoDB has no joins — "access patterns first": every query is pre-designed as partition key + sort key (+ GSI), multiple entities stuffed into one table distinguished by key prefixes (USER#/ORDER#), aggregates fetched in a single Query.
• At the edge: this is the steepest part of DynamoDB's learning curve — a need that in a relational database is "just add a join" becomes here = adding a GSI (more money) or redoing the key design (downtime migration); item splitting also matters: putting a frequently-changing small attribute and a static large attribute in the same item bills every update at the whole item's size — splitting into two items can cut a counter update from 2 WCU to 1 WCU; each new access pattern = a new GSI = a new bill — an old table's "query flexibility" was prepaid, not free.
• What it means for selection: someone on the team must be able to draw the "access pattern → key design" matrix, otherwise in three months you'll be stuck in the "add a table or add a GSI" swamp; startups are advised to "get the business working on PG first, then migrate stable hot paths to DynamoDB" (awslabs' official startup guidance) — don't play single-table design while requirements change daily.
• Sources: community skill docs (2026-09); awslabs startup-advisor (2026-09); community consensus

Deep-dive 6 (Replication & Consistency): Global Tables — LWW's silent drops vs. MRSC's three-region cage (domain: replication & disaster recovery)

• Mechanism: MREC (default): async replication (usually 1–2 seconds — official docs wording), concurrent writes to the same item converge via last-writer-wins; MRSC (new): synchronous quorum writes, conflicting writes throw ReplicatedWriteConflictException directly and let the application retry.
• At the edge: under MREC, two regions deducting inventory simultaneously means LWW silently drops one transaction — no conflict alert, no version vector; "eventually consistent" is consistent about "which write got dropped, without telling you"; MRSC builds a tight cage: fixed 3-region topology (including 1 witness), the region set can't span region groups, transactions/TTL unsupported, write latency = cross-region quorum RTT, and the bill = one rWCU write charge per region. And "multi-active access" is not "user routing" — DynamoDB doesn't do traffic steering for you; Route 53/application layer handles it.
• What it means for selection: for inventory/balance/counter data — where one lost write is an incident — under MREC you must pin writes to a region or use conditional writes; multi-writing natively under LWW is data loss by design; MRSC is only for "can't afford to lose but writes little" core data — and only after costing out latency and the bill; DR drills should test "how traffic cuts over when a region dies," not "whether the data arrived."
• Sources: official docs (Global Tables concepts page); aws.amazon.com Global Tables FAQ; community skill docs (2026-09)

1. Genuine zero-ops serverless Why it's real: no instances, no patches, no version upgrades, no "midnight scaling" — 14 years of production validation; the most tangible relief for teams that "don't want to hire a DBA team." Edge & limits: ops complexity moved to capacity modeling and FinOps; behavior changes (e.g., new-feature defaults) ship on a schedule you don't control; fewer firefighting tools than self-hosted (there's no "just connect and flip the parameter" move). Sources: official docs; community consensus. Observed version: serverless, continuously evolving
2. Single-digit-millisecond latency independent of scale Why it's real: partitioned-hash architecture — GetItem/Query latency doesn't grow with table size; for read-heavy, key-explicit workloads (sessions, carts, device shadows) this is an overwhelming advantage. Edge & limits: only holds for key-based access; Scan/aggregation is linear-cost; strong reads cost 2x RCU; DAX only accelerates eventually consistent reads. Sources: official docs (latency — vendor claim); community-tested. Observed version: all versions
3. On-demand pay-as-you-go, zero cost at cold start Why it's real: no traffic, no spend (except storage) — new businesses, tidal loads, and dev environments work out of the box; go live without capacity planning. Edge & limits: 5–7x the cost of provisioned under steady load (community wording); teams that "start on on-demand and figure it out later" are the worst bill-shock offenders; with a monthly bill >$100 and predictable traffic, switch to provisioned (community rule of thumb). Sources: community skill docs (2026-09); third-party cost analysis. Observed version: all versions
4. Global Tables multi-active worldwide Why it's real: multi-region simultaneous writes with local latency — global businesses (gaming, SaaS) don't have to build cross-border replication themselves; 99.999% SLA 厂商口径. Edge & limits: see Deep-dive 6 — LWW silent drops, the MRSC cage, replicated writes billed per region; traffic routing is your own job. Sources: official docs; community consensus. Observed version: MREC/MRSC dual mode, current
5. Dense AWS ecosystem integration Why it's real: Streams→Lambda event-driven, TTL auto-expiry, PITR, zero-ETL to S3/Redshift, IAM fine-grained permissions — all configured from one console; it's the default "state layer" in serverless architectures. Edge & limits: every integration has a ceiling (Streams 24h/2 consumers, non-punctual TTL, restore-only-to-new-table); the flip side of ecosystem integration is AWS lock-in — migrating away = rewriting the data-access layer. Sources: official docs; community consensus. Observed version: all versions

• One-line positioning: On AWS, the best serverless state layer for "key-based access, read-heavy, uncertain scale." But it's designed for "access patterns," not for "data models" — get the modeling wrong, and the bill and the rewrite will teach you a lesson.
• Best for:
  • Serverless/event-driven architectures on AWS needing single-digit-millisecond KV/document storage (sessions, carts, user profiles, device shadows, order headers)
  • High-concurrency OLTP with clear, stable access patterns, read-heavy, uniformly distributed keys
  • Global businesses needing multi-region low-latency reads/writes (MREC + region-pinned writes)
  • Unpredictable traffic: new businesses, tidal loads, dev/test environments (on-demand)
  • Teams needing out-of-the-box CDC (Streams→Lambda) for event-driven designs
• Not for:
  • Shifting query patterns, ad-hoc queries/aggregations/reporting (that's OLAP or search-engine work)
  • Multi-item complex transactions as the norm (the 100-item/4MB cap + 2x cost is a tight constraint)
  • Inventory/balance/counter data where "one lost write is an incident," yet multi-region simultaneous writes are desired (LWW silently drops)
  • Heavily relational modeling where joins are a hard requirement
  • Multi-cloud / xìnchuàng (IT localization) / open-source-self-hosting organizations; budget-sensitive small teams unwilling to do FinOps
• Migration cost:
  • MySQL → High: relational modeling rewritten as access-pattern modeling, joins pushed to the application layer or GSIs, transaction semantics redone
  • PostgreSQL → High: same as above; JSONB users note DynamoDB's document model is weaker (no GIN-style indexes)
  • Oracle → High: no Oracle compatibility path — not recommended as a "de-Oracle" target
  • Redis/Cassandra → Medium-low: KV thinking is close, but note DynamoDB has no Lua scripting/complex data structures, and Cassandra wide rows need key redesign

• Architecture & mechanisms: AWS official docs (Global Tables concepts, burst/adaptive capacity, Streams, PITR, encryption); aws.amazon.com Global Tables FAQ (MREC/MRSC wording)
• Billing model: AWS pricing pages cross-checked against third-party sources (on-demand $0.625/million writes, $0.125/million reads; provisioned $0.00065/WCU-hour, $0.00013/RCU-hour, verified 2026-08); absolute amounts are model references only — your AWS bill is authoritative
• Deep-dives & complaints: dev.to adaptive capacity analysis (2026-08); hackernoon cost analysis; Medium Rob Abbott GSI case (2025-10); awslabs startup-advisor skill docs (2026-09); multiple GitHub community skill docs (2026-09)
• To-be-verified: vector search 600GB allowlist details; a systematic list of DynamoDB Local vs. production behavior differences; Global Tables MRSC availability in China regions (Ningxia/Beijing)
• Next review: track production cases and performance wording after vector search GA; track MRSC region-set expansion and feature-limitation loosening; track on-demand pricing changes

Mechanical gap audit: all 14 fixed battery items answered with Supported/Unsupported/Partially supported/Not applicable + evidence level; "confirmed absent" (MySQL/PG/Oracle protocol compatibility, open-source distribution, in-place restore) distinguished from "no evidence found" (some China-region details); deep-dives cover 6 domains (storage engine / cost / indexing / replication & CDC / modeling / replication & consistency).