Khác biệt cốt lõi: quan hệ thì thiết kế theo dữ liệu rồi viết truy vấn sau; DynamoDB thì liệt kê hết access pattern trước rồi mới thiết kế khoá.
Mô hình khoá: partition key xác định phân vùng vật lý, sort key xác định thứ tự trong phân vùng. Truy vấn hiệu quả chỉ có hai dạng: lấy theo khoá chính, hoặc Query một partition key kèm điều kiện khoảng trên sort key. Không có JOIN. Scan toàn bảng là dấu hiệu thiết kế sai.
Hệ quả: dữ liệu được cố tình phi chuẩn hoá và gom sẵn theo cách sẽ đọc — nhiều loại thực thể có thể nằm chung một bảng với khoá tổng hợp (USER#123 / ORDER#2026-01-05) để một lần Query lấy đủ dữ liệu cho một màn hình.
Thiết kế partition key phải trải đều truy cập: khoá có ít giá trị (status, country) hoặc khoá tăng đơn điệu (ngày hiện tại) tạo phân vùng nóng, bị giới hạn throughput dù bảng tổng vẫn dư.
Chọn DynamoDB là sai khi:
- Access pattern chưa ổn định — sản phẩm mới còn đổi hằng tuần. Đổi cách truy vấn trong DynamoDB nghĩa là thêm index hoặc migrate dữ liệu, trong khi Postgres chỉ cần viết câu SQL khác.
- Cần truy vấn tuỳ ý, báo cáo, tổng hợp đa chiều — phải xuất sang kho khác mới làm được.
- Cần transaction phức tạp, ràng buộc toàn vẹn, unique nhiều cột.
- Dữ liệu bản chất là quan hệ nhiều-nhiều duyệt sâu (mạng xã hội, phân quyền lồng nhau).
- Chọn chỉ vì "để scale" trong khi tải thực tế còn cách xa giới hạn của một instance Postgres.
DynamoDB thắng rõ khi access pattern ít, biết trước, ổn định, và cần độ trễ mili-giây ổn định ở quy mô lớn với vận hành gần như bằng không.