DynamoDB vs PostgreSQL

Quick verdict

Amazon DynamoDB is a fully managed NoSQL service on AWS. You create tables, choose a primary key (a partition key, optionally with a sort key) and a capacity mode, and read items with GetItem, Query, Scan or PartiQL, a SQL-compatible language of which DynamoDB supports a subset. There is no engine version, instance or storage to manage, and on-demand capacity is the default mode. It runs only on AWS.

PostgreSQL is an open source object-relational database released under the PostgreSQL Licence, a permissive licence. The current release is 18.6. It offers standard SQL with joins, window functions, constraints and multi-version concurrency control, plus jsonb for semi-structured data. You can run it anywhere, or use a managed service such as Amazon RDS for PostgreSQL, Amazon Aurora PostgreSQL-Compatible Edition, or the equivalents on Azure and Google Cloud.

For DynamoDB against a document database, see DynamoDB vs MongoDB; for the broader trade-off, see SQL vs NoSQL.

Side by side

Key differences

Access-pattern-first design versus ad hoc queries

In DynamoDB you list the questions the application will ask before you design the table, then encode them in the partition key, sort key and secondary indexes. A read that names the partition key is efficient; one that does not is a scan. AWS's PartiQL documentation is explicit: a SELECT "can result in a full table scan if an equality or IN condition with a partition key is not provided in the WHERE clause", and it shows how to deny full-scan statements with an IAM policy.

-- DynamoDB (PartiQL): key-based read, served without a scan
SELECT OrderId, Total FROM "Orders" WHERE CustomerId = 'C123';

-- DynamoDB (PartiQL): filter on a non-key attribute = full table scan
SELECT OrderId, Total FROM "Orders" WHERE Total > 500;

In PostgreSQL you model entities and relationships, then answer new questions with SQL and add indexes as needed. The same table serves the application's key lookups and an analyst's one-off report.

-- PostgreSQL 18: the application query
SELECT order_id, total
FROM orders
WHERE customer_id = 123
ORDER BY order_date DESC
LIMIT 10;

-- PostgreSQL 18: an ad hoc report on the same table
SELECT customer_id, SUM(total) AS revenue
FROM orders
WHERE order_date >= DATE '2026-01-01'
GROUP BY customer_id
ORDER BY revenue DESC
LIMIT 5;

DynamoDB's PartiQL has no equivalent of the second query: AWS lists the supported functions as SIZE, EXISTS, ATTRIBUTE_TYPE, BEGINS_WITH, CONTAINS and MISSING, and states that any SQL function not on the list is unsupported. Teams that need reporting on DynamoDB data usually export it to an analytics service.

PartiQL is SQL-like, not SQL

PartiQL makes DynamoDB look familiar, but each statement still maps to single-item or key-based operations. An UPDATE or DELETE must identify exactly one item by its full primary key; AWS states that "you can only update one item at a time". Changing many items takes a batch or a transaction of individual statements.

-- DynamoDB (PartiQL): updates one item, identified by its full key
UPDATE "Orders" SET Status = 'SHIPPED'
WHERE CustomerId = 'C123' AND OrderId = 'O-1001';

-- PostgreSQL 18: one statement updates every matching row
UPDATE orders
SET status = 'SHIPPED'
WHERE customer_id = 123 AND status = 'PACKED';

Documents: DynamoDB items versus PostgreSQL JSONB

DynamoDB items are schemaless apart from the key attributes and can hold nested maps and lists up to the 400 KB item limit. PostgreSQL offers the same flexibility inside a relational table through jsonb, a decomposed binary format that the PostgreSQL documentation says is faster to process than json and supports indexing. A GIN index with the jsonb_path_ops operator class supports containment queries with @>.

-- PostgreSQL 18: relational columns plus a JSONB document
CREATE TABLE orders (
  order_id    bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  customer_id bigint NOT NULL,
  order_date  timestamptz NOT NULL DEFAULT now(),
  status      text NOT NULL,
  total       numeric(10,2) NOT NULL,
  attrs       jsonb
);
CREATE INDEX orders_attrs_gin ON orders USING GIN (attrs jsonb_path_ops);

SELECT order_id, attrs ->> 'channel' AS channel
FROM orders
WHERE attrs @> '{"channel": "mobile"}';

The result is that PostgreSQL can hold document-style data and still join it to relational tables and enforce constraints on the columns around it. DynamoDB has no joins, so related data is either duplicated into items or fetched with several requests.

Transactions and consistency

DynamoDB transactions (TransactWriteItems, TransactGetItems or PartiQL ExecuteTransaction) cover up to 100 actions and 4 MB within one account and Region. A PartiQL transaction must consist of either reads or writes, not both, with EXISTS allowed as a condition check. Reads are eventually consistent by default, and reads from global secondary indexes are always eventually consistent.

PostgreSQL transactions are ACID with no item cap: one transaction can update millions of rows, run DDL, and read its own writes. The default isolation level is Read Committed, and Repeatable Read and Serializable are available. Constraints, foreign keys and triggers are enforced inside the transaction, which is often the deciding factor for financial or inventory data.

Scaling and serverless relational options on AWS

DynamoDB partitions data and scales throughput for you; in on-demand mode there is no capacity to plan. A single PostgreSQL server scales vertically, adds read replicas for read traffic, and has no built-in sharding of writes across servers. That gap is the most common reason teams pick DynamoDB for very high write volumes.

AWS offers two ways to get serverless operations with a PostgreSQL interface. Amazon Aurora DSQL is a serverless, distributed relational service that AWS describes as PostgreSQL-compatible (currently with PostgreSQL 16), active-active across Availability Zones and, with peered clusters, across Regions in the same Region set. It has real differences from PostgreSQL: optimistic concurrency with retries on conflict, isolation fixed at Repeatable Read, up to 3,000 modified rows per transaction, one DDL statement per transaction, no temporary tables, triggers or PL/pgSQL, and no index support on json or jsonb columns. Aurora Serverless (formerly Aurora Serverless v2) is an autoscaling configuration of Aurora PostgreSQL or MySQL that adjusts capacity in 0.5 ACU steps and can scale to zero with automatic pause. For the wider choice between RDS and Aurora, see Amazon RDS vs Amazon Aurora; for distributed PostgreSQL-compatible databases outside AWS, see CockroachDB vs PostgreSQL.

Pricing and licensing

DynamoDB. Listed on the AWS DynamoDB on-demand pricing page in October 2026 for US East (N. Virginia), Standard table class, in USD: 0.625 per million write request units and 0.125 per million read request units, plus storage per GB-month. Provisioned capacity is billed per capacity unit per hour. Backups, streams, global tables and data transfer are charged separately, and rates vary by Region.

PostgreSQL. The software is free under the PostgreSQL Licence. Managed PostgreSQL is billed by the provider: Amazon RDS and Aurora provisioned clusters by instance hours, storage and (for some Aurora configurations) I/O, and Aurora Serverless by Aurora capacity units (ACUs) per second. Use the AWS Pricing Calculator for these.

Aurora DSQL. Listed on the Aurora DSQL pricing page in October 2026: billed by Distributed Processing Units (DPUs) for database activity and GB-months of storage, with DPU charges scaling to zero when idle. In US East (Ohio), 8 USD per million DPUs and 0.33 USD per GB-month; each month the first 100,000 DPUs and 1 GB of storage are free. We have not estimated workload costs; DPU use depends on the queries you run.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You want SQL and PostgreSQL drivers with serverless operations on AWS: consider Aurora DSQL or Aurora Serverless, after checking DSQL's PostgreSQL compatibility limits; see Amazon RDS vs Amazon Aurora.
• You want a document database with richer queries than DynamoDB: see DynamoDB vs MongoDB and MongoDB vs PostgreSQL.
• You need a cache or session store in front of the database: see Redis vs MongoDB.
• Your workload is analytics over large volumes: a warehouse fits better; see data warehouse vs database.

Final recommendation

Frequently asked questions

Sources

• Amazon DynamoDB Developer Guide: PartiQL
• Amazon DynamoDB Developer Guide: PartiQL SELECT
• Amazon DynamoDB Developer Guide: PartiQL functions
• Amazon DynamoDB Developer Guide: PartiQL transactions
• Amazon DynamoDB Developer Guide: Constraints
• Amazon DynamoDB on-demand pricing
• Amazon Aurora DSQL User Guide
• Aurora DSQL: PostgreSQL compatibility considerations
• Aurora DSQL pricing
• Amazon Aurora User Guide: Aurora Serverless
• PostgreSQL documentation: JSON types
• PostgreSQL documentation: Transaction isolation
• PostgreSQL documentation: Limits
• PostgreSQL licence
• PostgreSQL versioning policy

Checked October 2026.

How we research comparisons: our editorial method.