This post is maintained by Bytebase, an open-source database DevSecOps tool that can manage both DynamoDB and PostgreSQL. We update the post every year.
| Update History | Comment |
|---|---|
| 2025/04/22 | Initial version. |
This post compares Amazon DynamoDB and PostgreSQL, focusing on their key differences, strengths, and ideal use cases. We position PostgreSQL as the well-known baseline and examine when DynamoDB might be a better alternative.
DynamoDB Overview
Amazon DynamoDB is a fully managed, serverless NoSQL database service designed for web-scale applications. Launched by AWS in 2012, it overcomes scaling and operational challenges of traditional relational databases. As a key-value and document database, DynamoDB supports both simple primary key access and more complex document structures without schema constraints.
License Model
DynamoDB is a proprietary AWS service with a pay-as-you-go model:
- On-Demand: Pay per request (no commitment)
- Provisioned: Pre-allocated capacity (discounts for reservations)
- Free Tier: Limited usage for new accounts
Exclusive to AWS — no self-hosted option. Fully managed.
Architecture and Design Philosophy
DynamoDB's architecture is built around a distributed, partitioned design:
- Request Router: Directs API requests to appropriate partitions
- Partitioning Layer: Distributes data across nodes based on partition keys
- Storage Layer: Manages data persistence on SSDs with automatic replication
- Metadata Service: Tracks partition locations and schema information
- Authentication Layer: Integrates with AWS IAM for access control
This design allows DynamoDB to distribute data automatically across multiple servers based on partition key values, enabling horizontal scaling without performance degradation.
Performance Characteristics
DynamoDB delivers consistent, single-digit millisecond response times regardless of data volume or traffic patterns. This predictable performance is maintained whether you're dealing with megabytes or hundreds of terabytes of data. During peak events like Prime Day, DynamoDB has demonstrated its ability to handle trillions of requests while maintaining performance guarantees.
Performance is optimized for specific access patterns:
- Key-based operations: Consistent millisecond response (table size independent)
- Eventually consistent reads: Higher throughput (default)
- Strongly consistent reads: Latest data at slightly higher cost/latency
- Scans: Performance degrades with table size (avoid for large datasets)
Scalability
DynamoDB is designed for massive scale with:
- Automatic horizontal scaling via partitioning
- Virtually unlimited table size and throughput
- Two capacity modes: provisioned (with auto-scaling) and on-demand
- Scale-to-zero support in on-demand mode
- Seamless scaling without downtime or performance hits
- Global Tables for multi-region, multi-active replication
SQL Compatibility
DynamoDB does not support standard SQL:
- Uses a proprietary JSON-based API
- PartiQL enables limited SQL-like syntax for basic operations
- No joins or complex queries
- Transaction support capped at 100 items or 4MB
- No stored procedures or triggers
Deployment Options
DynamoDB is available exclusively as a managed AWS service:
- Standard Tables: Single-region deployment with cross-AZ replication
- Global Tables: Multi-region deployment with active-active replication
- DynamoDB Accelerator (DAX): In-memory caching for DynamoDB
- DynamoDB Streams: Change data capture for event-driven architectures
DynamoDB vs. PostgreSQL
Comparison Table
| Aspect | PostgreSQL | DynamoDB |
|---|---|---|
| License | Open Source (PostgreSQL License) | Proprietary AWS Service |
| Architecture | Traditional client-server RDBMS | Distributed NoSQL database |
| Data Model | Relational with structured schemas | Key-value and document with flexible schemas |
| Query Language | Full SQL support | Proprietary API with limited PartiQL support |
| Horizontal Scaling | Manual (sharding, read replicas) | Native, automatic |
| Vertical Scaling | Excellent | Not applicable |
| Consistency | ACID compliant | Eventually consistent by default, optional strong consistency |
| Transactions | Full ACID transactions | Limited transactions (max 100 items or 4MB) |
| Performance | Variable, depends on query complexity | Consistent single-digit millisecond latency |
| Joins | Complex joins supported | No native join support |
| Indexing | Multiple index types, unlimited indexes | Limited to 5 LSIs and 20 GSIs per table |
| Management | Self-managed or managed service | Fully managed service only |
| Global Distribution | Possible with additional tools | Built-in with Global Tables |
| Cost Model | Infrastructure-based | Usage-based (throughput and storage) |
| Ecosystem | Rich ecosystem of tools and extensions | Limited to AWS ecosystem |
| Best For | Complex queries, relationships, data integrity | High-scale applications with simple access patterns |
License and Cost
PostgreSQL is truly open-source under the PostgreSQL License, which is similar to the MIT license. This permissive license allows for free use, modification, and distribution in any context, including commercial applications. PostgreSQL can be self-hosted on any infrastructure or used through various managed service providers.
DynamoDB, in contrast, is a proprietary service available only through AWS with a pay-as-you-go pricing model. While there are no upfront licensing costs, ongoing usage fees can become significant for high-throughput applications or large data volumes.
The cost implications differ substantially:
- PostgreSQL incurs infrastructure and operational costs (compute, storage, administration)
- DynamoDB charges based on usage — read/write throughput and storage
- PostgreSQL offers more predictable costs but requires capacity planning
- DynamoDB can achieve near-zero idle costs with on-demand pricing
Architecture and Scalability
PostgreSQL follows a traditional client-server model with a single primary handling writes. Its process-per-connection design offers strong isolation but can struggle at scale. Common scaling strategies include:
- Vertical scaling (larger compute instances)
- Read replicas to offload read traffic
- Connection pooling to manage high concurrency
- Manual sharding, which requires application-level logic
DynamoDB is built for scalability with a distributed, serverless architecture. It automatically partitions data based on keys, offering:
- Seamless horizontal scaling
- No theoretical limits on throughput or storage
- Minimal operational overhead, but with limited query flexibility
Performance Characteristics
Both databases offer strong performance, but excel in different scenarios:
PostgreSQL:
- Performance varies with query complexity and optimization
- Advanced query planner supports complex joins and aggregations
- Ideal for analytical workloads with proper indexing
- Requires tuning as data volume grows
- Buffer cache accelerates access to hot data
DynamoDB:
- Delivers consistent single-digit millisecond latency
- Optimized for key-value access patterns
- Limited support for complex queries or joins
- Maintains performance at massive scale
- Predictable latency simplifies capacity planning
SQL Compatibility and Ecosystem
PostgreSQL offers full SQL support with a robust and extensible ecosystem:
- Standards-compliant SQL with advanced capabilities
- Support for procedural languages (e.g., PL/pgSQL, PL/Python)
- Extensive extension ecosystem (e.g., PostGIS, TimescaleDB)
- Foreign data wrappers to access external data sources
- Custom data types, operators, and functions
- Mature tooling for development, monitoring, and administration
DynamoDB uses a proprietary API with limited SQL-like access via PartiQL:
- No native SQL, Steeper learning curve for SQL-based teams
- Limited tool compatibility with traditional SQL workflows
- Simplified CRUD operations for key-value access
- Strong AWS ecosystem integration
- Fewer options for complex queries and analytics
Data Modeling and Flexibility
PostgreSQL follows a relational model with strong data integrity features:
- Structured tables with defined schemas
- Foreign keys for managing complex relationships
- Rich data types including arrays, JSON, and custom types
- Schema evolution via ALTER TABLE
- Constraints to enforce data integrity (e.g., UNIQUE, CHECK)
- Normalization to reduce redundancy and improve consistency
DynamoDB uses a flexible, schema-less design optimized for scalability:
- No fixed schema — only primary key attributes are mandatory
- Dynamic attributes can be added/removed per item
- Single-table design for storing diverse entity types
- Denormalized models favor query speed over data reuse
- Limited relationship support, typically handled in application logic
When to Use PostgreSQL
PostgreSQL is a powerful, general-purpose database ideal for a wide range of applications. It shines in the following scenarios:
- Complex queries and relationships (e.g., CMS, ERP, financial systems)
- Strong data integrity via constraints, triggers, and enforced rules
- Analytical capabilities with CTEs, window functions, and OLAP support
- Extensibility for geospatial, JSON, custom types, and full-text search
When to Use DynamoDB
While PostgreSQL suits most use cases, DynamoDB excels in specific scenarios:
- Extreme scalability for high-throughput, low-latency workloads
- Simple, key-based access patterns like user profiles or product catalogs
- Serverless architecture with minimal operational overhead
- Global distribution with low-latency multi-region replication
- Cost efficiency for unpredictable or spiky workloads
Conclusion
PostgreSQL is a versatile default for most applications with rich queries, strong integrity, and extensibility. DynamoDB excels in high-scale, low-maintenance environments — especially for key-based access, serverless apps, or global workloads.
Base your choice on access patterns, scalability demands, and team skills. A hybrid model can also balance the strengths of both.
