The short version: in 2026, I'd still default to Postgres first for the vast majority of new applications—even ones with a mix of relational and document-like data. The ecosystem has only gotten stronger, and the "Postgres + JSONB" pattern has become even more established.
The decision usually comes down to what kind of scaling you actually expect.
| If your primary concern is... | I'd lean toward... |
|---|
| Complex relationships, joins, transactions | Postgres |
| Mostly relational with some flexible fields | Postgres + JSONB |
| Massive key-value workloads at AWS scale | DynamoDB |
| Multi-region SQL with active writes everywhere | CockroachDB |
| Unknown startup requirements | Postgres |
Postgres + JSONB
This has become the default architecture for many modern SaaS products.
Advantages:
- Excellent relational modeling
- ACID transactions
- Mature indexing (including GIN indexes for JSONB)
- Strong SQL ecosystem
- Easy analytics
- Flexible schema evolution where needed
A common pattern looks like:
users
orders
subscriptions
event_data
---------
id
user_id
type
payload JSONB
created_at
or
products
---------
id
sku
price
attributes JSONB
The relational columns stay relational.
Only the changing, sparse, or customer-specific fields go into JSONB.
That tends to age much better than making everything into documents.
DynamoDB
I'd only choose DynamoDB if I knew from day one that my access patterns matched it.
It's fantastic when:
- access patterns are known ahead of time
- extremely high throughput is expected
- latency is critical
- data is mostly key-value
- you're already deeply invested in AWS
But there are tradeoffs:
- no joins
- data modeling is very different
- changing query patterns later can be painful
- secondary indexes require planning
Many teams underestimate how much upfront modeling DynamoDB requires.
CockroachDB
Cockroach has matured significantly.
Its biggest strength remains:
SQL with automatic horizontal scaling and multi-region replication.
It's attractive when you need:
- customers worldwide
- active-active regions
- strong consistency
- SQL instead of NoSQL
For example:
with writes occurring locally in each region.
That's difficult to achieve with vanilla Postgres.
Tradeoffs include:
- operational complexity compared with managed Postgres
- some SQL features and performance characteristics differ from PostgreSQL
- tuning distributed SQL is a different skill than tuning a single Postgres instance
International scaling
This is where people often optimize too early.
Many applications can comfortably reach very large scale on Postgres before needing distributed SQL.
A typical progression is:
Managed Postgres
↓
Read replicas
↓
Connection pooling
↓
Caching (Redis)
↓
Partitioning
↓
Regional read replicas
↓
Only then consider distributed SQL
Many successful SaaS companies stayed on Postgres far longer than people expected.
Mixing relational and document data
A common mistake is putting everything into JSON.
Instead:
Good:
orders
--------
id
customer_id
status
total
metadata JSONB
Bad:
{
"customer": {...},
"items": [...],
"shipping": {...},
"payments": {...}
}
If you routinely filter, sort, join, or aggregate on a field, it usually belongs in a normal column.
If the structure changes frequently or varies by customer, JSONB is a good fit.
If I were starting a greenfield SaaS in 2026
My default stack would likely be:
- Postgres as the primary database
- JSONB for flexible metadata rather than core business entities
- Redis for caching and ephemeral state
- Object storage for large blobs/files
- Event streaming only if there's a clear need, rather than by default
I'd only reach for CockroachDB if I knew I needed multi-region active writes from the outset, and I'd choose DynamoDB only if my workload naturally fit a key-value or single-table design and I was comfortable designing around its access patterns.
Rule of thumb
- 80–90% of new applications: Postgres (+ JSONB where appropriate)
- Global, active-active SQL requirements: CockroachDB
- Very high-scale key-value workloads with predictable access patterns: DynamoDB
That aligns with current industry practice in 2026: start with the simplest database that matches your data model, and move to distributed databases only when your scaling or geographic requirements justify their added complexity.
