← Back to Blog Cloud Architecture

DocumentDB vs DynamoDB: Choosing NoSQL on AWS for Financial Services Data

10 min read December 15, 2025 Laniakea Consulting Team

Two Databases That Solve Different Problems

Financial services firms moving from on-premises MongoDB or Oracle document stores to AWS NoSQL face a choice that looks simple on the surface: DocumentDB or DynamoDB. AWS positions both as managed NoSQL services. The marketing pages emphasize scalability, availability, and security. The architectural differences — which determine whether your application works well or fights the database on every query — are buried in documentation.

DocumentDB is a MongoDB-compatible document database with a traditional cluster architecture: primary instances, read replicas, storage that scales independently. DynamoDB is a serverless key-value and document store built for single-digit millisecond access at any scale. They share a category label (NoSQL) and almost nothing else in terms of query patterns, scaling behavior, and operational model.

For financial services workloads — where compliance requirements, query complexity, and audit trails matter as much as latency — the choice requires understanding what each database is actually good at, not what the feature comparison table says.

<10ms

DynamoDB read latency (p99)

15+

DocumentDB read replicas max

64 TB

DocumentDB max storage per cluster

When DocumentDB Wins

Complex Aggregation Pipelines

Financial services data is rarely simple key-value. Transaction analytics, risk calculations, and regulatory reporting require aggregation pipelines that group, filter, join, and transform documents across collections. DocumentDB supports the MongoDB aggregation framework — $match, $group, $lookup, $unwind, $project — which lets you express these queries in a single pipeline.

DynamoDB has no aggregation framework. Every "aggregation" is either pre-computed (maintained by application code on write) or performed by scanning data into application memory and computing there. For a query like "total transaction volume by merchant category for accounts flagged for review in the last 90 days," DocumentDB handles this natively. DynamoDB requires you to architect around the limitation.

Ad-Hoc Queries

Compliance teams, risk analysts, and fraud investigators run ad-hoc queries. They don't know in advance which fields they'll filter on or which documents they need. DocumentDB supports flexible queries on any field with secondary indexes — the same query patterns MongoDB developers are accustomed to.

DynamoDB requires you to define access patterns up front. Every query must use a partition key, and secondary access patterns require Global Secondary Indexes (GSIs) that must be created before the query exists. Ad-hoc queries against fields not covered by a GSI require a full table scan — expensive and slow on large tables.

Existing MongoDB Applications

If the team has a running MongoDB application, DocumentDB is the lower-friction migration path. The MongoDB wire protocol compatibility means the application's connection string changes, but the queries, indexes, and driver code remain largely the same. Not everything is compatible — DocumentDB doesn't support all MongoDB features (e.g., client-side field-level encryption, change streams with certain options) — but the migration effort is significantly less than rewriting for DynamoDB's data model.

VPC Isolation for Compliance

DocumentDB runs exclusively inside a VPC. There is no public endpoint. Every connection must come from within the VPC or through a VPN/Direct Connect path. For financial services firms subject to SOC 2, PCI DSS, or OCC regulatory requirements, this default-private architecture simplifies the compliance narrative. DynamoDB has VPC endpoints (Gateway endpoints for DynamoDB), but the service itself is multi-tenant by design — your data lives in a shared infrastructure managed by AWS.

When DynamoDB Wins

Simple Access Patterns at Extreme Scale

If the workload is "get account by ID," "get transactions by account ID and date range," or "put transaction record" — and the access patterns are known and fixed — DynamoDB is purpose-built for this. Single-digit millisecond latency at any scale, with no capacity planning for read/write throughput beyond setting RCU/WCU or using on-demand mode.

Serverless Architecture

DynamoDB requires no instance management. No patching, no failover configuration, no replica promotion. For teams building event-driven architectures with Lambda, API Gateway, and Step Functions, DynamoDB fits naturally. DocumentDB requires managing instances, choosing instance types, and handling maintenance windows — operational overhead that serverless teams may not want.

Global Distribution

DynamoDB Global Tables provide multi-region, active-active replication with conflict resolution. For financial services firms that need transaction data available in multiple AWS regions (US, EU, APAC) with local read/write capability, Global Tables solve this natively. DocumentDB does not offer multi-region write capability — you can create cross-region read replicas, but writes go to a single primary region.

Financial Services Compliance: Head-to-Head

Encryption

Both services encrypt data at rest using AWS KMS. DocumentDB encrypts the underlying storage volume, backups, and replicas using a single KMS key per cluster. DynamoDB encrypts each table with either an AWS-owned key, an AWS-managed key, or a customer-managed KMS key.

The practical difference: DocumentDB's encryption is cluster-wide and always on (you cannot create an unencrypted cluster). DynamoDB's encryption is table-level and also always on, but the key management options are more granular. Both support encryption in transit via TLS — DocumentDB requires TLS by default, DynamoDB uses HTTPS endpoints.

Audit Logging

DocumentDB supports two levels of audit logging: DML auditing (which queries were executed, by which user, against which collections) and DDL auditing (schema changes). These logs go to CloudWatch Logs. Combined with the database profiler, you get query-level audit trails suitable for SOX and PCI DSS requirements.

DynamoDB audit logging is through CloudTrail (control plane operations: CreateTable, UpdateTable, DeleteTable) and DynamoDB Streams (data plane: item-level changes). CloudTrail captures who made API calls; Streams capture what changed in the data. For regulatory audit trails on data changes, you need DynamoDB Streams enabled and a consumer (Lambda function, Kinesis Data Streams) that writes the change records to a durable audit store.

// DocumentDB: Aggregation pipeline for transaction analysis
// Find total volume by merchant category for flagged accounts, last 90 days
db.transactions.aggregate([
  { $match: {
    account_status: "flagged",
    transaction_date: {
      $gte: ISODate("2025-09-15T00:00:00Z")
    }
  }},
  { $group: {
    _id: "$merchant_category",
    total_volume: { $sum: "$amount" },
    transaction_count: { $sum: 1 },
    avg_amount: { $avg: "$amount" },
    unique_accounts: { $addToSet: "$account_id" }
  }},
  { $project: {
    merchant_category: "$_id",
    total_volume: 1,
    transaction_count: 1,
    avg_amount: { $round: ["$avg_amount", 2] },
    unique_account_count: { $size: "$unique_accounts" }
  }},
  { $sort: { total_volume: -1 } }
])
    

// DynamoDB equivalent: requires pre-designed GSI + application-side aggregation
// Step 1: Query transactions using GSI on account_status + transaction_date

const params = {
  TableName: "Transactions",
  IndexName: "StatusDateIndex",  // GSI: PK=account_status, SK=transaction_date
  KeyConditionExpression:
    "account_status = :status AND transaction_date >= :since",
  ExpressionAttributeValues: {
    ":status": { S: "flagged" },
    ":since": { S: "2025-09-15T00:00:00Z" }
  }
};

// Step 2: Paginate through ALL results (DynamoDB returns 1MB per page)
let items = [];
do {
  const result = await dynamodb.query(params).promise();
  items = items.concat(result.Items);
  params.ExclusiveStartKey = result.LastEvaluatedKey;
} while (params.ExclusiveStartKey);

// Step 3: Aggregate in application code (what DocumentDB does natively)
const grouped = items.reduce((acc, item) => {
  const cat = item.merchant_category.S;
  if (!acc[cat]) acc[cat] = { total: 0, count: 0, accounts: new Set() };
  acc[cat].total += parseFloat(item.amount.N);
  acc[cat].count += 1;
  acc[cat].accounts.add(item.account_id.S);
  return acc;
}, {});
    

The DocumentDB version is a single database query. The DynamoDB version requires a pre-defined GSI, pagination logic, and application-side aggregation. For a one-off compliance report, the DocumentDB approach is dramatically simpler. For a real-time dashboard serving thousands of requests per second with a fixed access pattern, the DynamoDB approach — pre-computed and stored in a summary table — will outperform DocumentDB.

Backup and Recovery

DocumentDB provides continuous backup with point-in-time recovery (PITR) to any second within the retention window (up to 35 days). Restoring creates a new cluster from the backup — the process takes minutes to hours depending on data volume.

DynamoDB provides PITR with the same 35-day retention window, plus on-demand backups that persist indefinitely. DynamoDB restores also create a new table. The operational difference: DynamoDB restores are typically faster for large datasets because the underlying storage architecture is designed for it.

Cost at Scale

DocumentDB pricing is instance-based: you pay for the instances you provision (db.r6g.large at ~$0.277/hr, db.r6g.xlarge at ~$0.554/hr) plus storage ($0.10/GB-month) plus I/O ($0.20 per million requests). This is predictable but not elastic — you pay for provisioned capacity whether you use it or not.

DynamoDB pricing is either provisioned (RCU/WCU) or on-demand (per-request). On-demand pricing is $1.25 per million write request units, $0.25 per million read request units, plus storage at $0.25/GB-month. For bursty workloads, on-demand can be expensive; for steady workloads, provisioned with auto-scaling is more economical.

For a typical financial services workload — 500GB of data, 5,000 reads/sec and 1,000 writes/sec sustained — DocumentDB on a db.r6g.xlarge with a read replica runs approximately $1,200-1,500/month. DynamoDB provisioned with the same throughput runs approximately $800-1,100/month. The cost advantage shifts toward DocumentDB when query complexity increases (because complex DynamoDB queries consume more RCUs and require more GSIs with their own storage and throughput costs).

The decision framework is straightforward: if your queries are complex, your access patterns evolve, and your team knows MongoDB — choose DocumentDB. If your access patterns are fixed, your scale requirements are extreme, and you're building serverless — choose DynamoDB. The financial services compliance requirements (encryption, audit, VPC isolation) are achievable on both, with different implementation effort.

The Hybrid Approach

Some financial services architectures use both. DynamoDB for the transaction processing path — high-throughput, low-latency writes for incoming transactions — and DocumentDB for the analytical and compliance path — complex queries, ad-hoc reporting, regulatory data pulls. DynamoDB Streams feeds changes to a Lambda function that writes to DocumentDB, giving you the performance of DynamoDB on the write path and the query flexibility of DocumentDB on the read path.

This adds operational complexity. Two databases to monitor, two backup strategies, a streaming pipeline to maintain. But for organizations where the access pattern genuinely splits between "fast simple writes" and "complex analytical reads," it's a defensible architecture.

Need Help Choosing the Right Database Architecture?

We design and operate NoSQL architectures on AWS for financial services workloads. Whether it's DocumentDB, DynamoDB, or a hybrid approach, we'll help you choose based on your actual access patterns and compliance requirements — not marketing materials.

Talk to Our Team