DynamoDB vs PostgreSQL: Which database fits your workload?

Choose DynamoDB when your application has known key-based access patterns, needs elastic throughput, and benefits from AWS managing the database infrastructure. Choose PostgreSQL when joins, relational constraints, flexible SQL queries, and transactions across related records are central to the application. Both support ACID transactions; the important differences are query flexibility, transaction scope, scaling architecture, and operating cost.

DynamoDB and PostgreSQL: an overview

DynamoDB is a managed key-value and document database. You define table and index keys, then use APIs to read and write items. AWS manages storage distribution and replication, but you still design access patterns, monitor throttling, and configure recovery.

PostgreSQL is an open-source object-relational database with SQL, custom types, functions, and extensions. It can run locally, on your own infrastructure, or as a managed cloud service. As of October 23, 2026, PostgreSQL 18 is the current stable major version; PostgreSQL 19 is a release candidate, according to the official release list. A managed provider can support a different set of versions and extensions.

DynamoDB vs PostgreSQL at a glance

The limits above come from DynamoDB constraints and PostgreSQL limits. They are design boundaries, not a benchmark of either system.

1. Data model and query capabilities

DynamoDB

A DynamoDB item must have its table's partition key and, where defined, sort key. Other attributes can vary between items, but values still have types and the whole item must fit within 400 KB. Flexible attributes do not remove the need for a deliberate schema in application code.

For a shopping cart, a customer identifier can be the partition key and a product identifier the sort key. Reading one customer's cart becomes a key query. A report that groups purchases by supplier, country, and month is a different access pattern: it may need another index, a maintained aggregate, or an analytical system. A filter on a scan does not make the scan cheap because filtering happens after items are read.

PartiQL provides SQL-compatible syntax for supported DynamoDB operations. It does not turn DynamoDB into a relational query engine or add joins. Plan your DynamoDB data model around the reads and writes the application actually performs.

PostgreSQL

PostgreSQL stores relationships explicitly through primary keys, foreign keys, uniqueness constraints, and joins. That fits orders, order lines, inventory, invoices, and other entities whose relationships must remain valid as the application changes.

It also supports documents. The JSON types documentation explains how jsonb stores parsed JSON and supports indexing. A product table can keep stable fields in typed columns and variable product attributes in JSONB. Choosing PostgreSQL does not require every incoming document to become a separate set of relational tables.

PostgreSQL's extensibility remains useful: custom functions and types can keep specialized behavior near the data. Verify extension availability before choosing managed hosting; providers do not necessarily permit every extension you could install yourself.

2. Latency, performance and scaling

DynamoDB

DynamoDB is designed for predictable, low-latency operations with good key distribution. Its managed partitioning makes large key-based workloads practical, but it does not guarantee constant end-to-end latency for every query or traffic spike. Large items, hot keys, indexes, retries, and the distance between the application and AWS Region all matter.

On-demand mode adjusts capacity automatically within its scaling behavior and quotas. Warm throughput describes the rate a table or index can immediately sustain; pre-warming can prepare for a planned spike. Provisioned mode lets you allocate capacity and use auto scaling. Neither mode fixes a single overloaded key.

DAX is an optional cache for suitable read-heavy workloads. Measure cache hit rate, consistency requirements, and cluster cost before adding it. A cache-hit measurement is not comparable to an uncached PostgreSQL query.

PostgreSQL

PostgreSQL performance depends on query plans, indexes, memory, storage, concurrency, and maintenance. Its index types include B-tree, GIN, GiST, SP-GiST, BRIN, and hash indexes. Partitioning, covering indexes, and query planning can make a substantial difference before an application needs sharding.

Read replicas can offload eligible reads. They do not automatically distribute writes to arbitrary independent primaries. For high write volume, evaluate schema and query changes, larger instances, partitioning, or a distributed PostgreSQL-compatible service with its own semantics.

Monitor connection count, cache behavior, slow queries, deadlocks, storage growth, and replica lag. Managed hosting reduces infrastructure work; it does not make inefficient SQL free. Compare both databases using the same workload, consistency, data size, and latency percentiles.

JSON, vector search and spatial workloads

The pgvector extension supports exact nearest-neighbor search and approximate indexes such as HNSW and IVFFlat. This lets an application combine vector results with relational filters. It is an extension, not a feature installed automatically on every PostgreSQL service.

DynamoDB also has native vector indexes and SearchVectors for on-demand tables, so vector search alone is no longer a reason to rule it out. Compare filtering, recall, update rate, and query composition. PostgreSQL with PostGIS is particularly relevant when geometric types and spatial analysis are central requirements.

3. Availability and durability

DynamoDB replicates data across Availability Zones within a Region. Global tables add multi-Region replication, with eventual consistency (MREC) or strong consistency (MRSC). MREC transactions are atomic only in the originating Region; MRSC does not support transaction APIs. Regional replication is not a backup against an application deleting the wrong data.

For PostgreSQL, availability depends on the deployment. The project documents replication and high-availability approaches, including primary/standby designs. Your team or managed provider must arrange failover, client reconnection, replication settings, and recovery testing. Asynchronous replicas can lag, so direct reads requiring the latest committed state appropriately.

There is no universal availability SLA for PostgreSQL itself. Compare the specific managed plan or self-managed design with DynamoDB's service terms and your application's recovery objectives.

4. Security

DynamoDB encrypts stored data and integrates with IAM, resource-based policies, and AWS KMS key options. A VPC endpoint provides a private access path to the managed service; it does not place a DynamoDB instance inside your VPC. Apply least-privilege permissions to tables, indexes, and streams.

PostgreSQL offers database roles, object privileges, TLS connections, and row-level security policies. Network restrictions and authentication configuration are part of deployment. Row security needs careful role design because owners and privileged roles can bypass policies in documented circumstances.

Encryption options distinguish transport, column, and storage-level protection. Managed-service encryption, audit facilities, private networking, and key management depend on the provider. Neither database becomes secure merely because it supports encryption.

5. Backups and recovery

DynamoDB offers on-demand backups and point-in-time recovery with a configurable window of 1 to 35 days. PITR restores into a new table, so a recovery procedure must also reconnect the application and restore operational settings. It is not automatic cross-Region backup replication. See the backup and restore guide.

PostgreSQL's backup documentation distinguishes SQL dumps, filesystem-level backups, and continuous archiving. A base backup plus the required write-ahead log supports point-in-time recovery. Replication and hot standby improve availability but are not substitutes for independently retained backups.

Managed providers can automate backups and restores, but retention, regional copies, and charges differ. Test a restore and measure how long the application takes to become usable; a successful backup job alone does not prove recovery.

6. Pricing and managed PostgreSQL options

DynamoDB pricing charges for on-demand requests or provisioned capacity, plus storage and optional services. On-demand suits variable or initially unknown traffic. Provisioned capacity can be economical for sustained, predictable utilization, but you pay for allocated capacity even when idle. Index writes, replication, backups, and DAX can change the total substantially.

The Standard-class free allowances include 25 GB of storage and 25 provisioned read and write capacity units per Region and payer account. The provisioned capacity allowance does not cover on-demand read/write requests. Model actual item sizes and access patterns with the DynamoDB pricing calculator.

PostgreSQL has no license fee, but production infrastructure and operations cost money. Amazon RDS for PostgreSQL provides managed instances, backups, Multi-AZ options, and read replicas. Its pricing depends on instance deployment, storage, I/O choices, backups, and other usage.

Aurora PostgreSQL is a separate managed PostgreSQL-compatible engine. Aurora DSQL is a serverless distributed SQL service with PostgreSQL compatibility, but has its own supported feature set. Do not assume extensions, procedural code, or every PostgreSQL behavior transfer unchanged to DSQL.

DigitalOcean remains another managed option. Its pricing documentation distinguishes single-node and highly available plans; the latter includes a primary and a separately charged matching standby. Compare the full deployment, not the advertised price of one node against an entire DynamoDB application.

When to use DynamoDB

Choose DynamoDB for sessions, shopping carts, device state, game state, and other workloads dominated by well-defined key lookups and updates. It is especially attractive when AWS integration and removing server administration matter more than ad hoc SQL.

Inventory can fit, but correctness must be explicit: use conditional writes and, where appropriate, transactions. High concurrency alone does not make DynamoDB the right choice if every request requires a different relationship-heavy query.

When to use PostgreSQL

Choose PostgreSQL for relational OLTP, financial records, business applications, reporting queries, and evolving requirements where joins and integrity constraints reduce application complexity. JSONB, PostGIS, and pgvector broaden its usefulness without abandoning SQL.

It is also a reasonable starting point for a small application. Do not introduce denormalization and synchronization machinery solely because a future workload might become large. Measure the actual bottleneck and compare managed options before moving data.

Can you use DynamoDB and PostgreSQL together?

Yes. One design keeps orders and payments in PostgreSQL while DynamoDB serves sessions or a purpose-built read model. Another processes DynamoDB Streams into PostgreSQL for queries that need relational joins.

Give each entity a clear source of truth. A direct write to both databases can succeed in one and fail in the other; use an outbox or change-data-capture workflow, idempotent consumers, and reconciliation. Define acceptable propagation lag before exposing a copied view to users. Neither database provides an automatic atomic transaction across the pair.