MongoDB vs Postgres JSONB: When Each Wins
Fast recall
Quick revision
Core answer
GIN (jsonb_path_ops) indexes on the flexible parts. MongoDB wins when documents are the primary model, shapes genuinely vary per document, you lean hard on the aggregation pipeline, you need built-in sharding past single-node capacity, or your team wants change streams and flexible schema out of the box. The honest comparison: for 80% of 'I need a document DB' use cases, Postgres JSONB + `pg_trgm` + `pgvector` is lower-ops and simpler; MongoDB pulls ahead when aggregation pipelines, sharding, or true document variability dominate.Whether you can pick between Postgres JSONB and MongoDB based on real workload characteristics, not buzzwords
Assuming MongoDB is always faster or that Postgres can't handle JSON well
Show GIN jsonb_path_ops vs jsonb_ops trade-offs, MongoDB aggregation pipeline, sharding inflection point, and honest performance numbers
Interview-ready guide
Interview answer
Frame the two stories
- Postgres JSONB: relational DB with first-class JSON
- MongoDB: the document is the row; everything is JSON-native
Give the decision heuristic
- Most queries relational + a few flex fields → Postgres JSONB
- Most queries on nested document shape that varies → MongoDB
- Heavy aggregation pipelines → MongoDB
- Multi-row transactions common → Postgres
- Past single-node write capacity → MongoDB sharding (or Citus/Aurora)
Mention the ergonomics
- GIN
jsonb_path_opsfor containment queries - MongoDB aggregation pipeline + change streams out of the box
- Postgres window functions + CTEs + vector + full-text in one store
Close honestly
- For 80% of 'I need flexible documents', Postgres is simpler and lower ops
- MongoDB pulls ahead when pipelines, sharding, or true variability dominate
MongoDB vs Postgres JSONB: When Each Wins
Direct Answer
Postgres JSONB is the default when your data is mostly relational with a few flexible fields — you get real joins, ACID multi-row transactions, window functions, and GIN (jsonb_path_ops) indexes on the flexible parts. MongoDB wins when documents are the primary model, shapes genuinely vary per document, you lean hard on the aggregation pipeline, you need built-in sharding past single-node capacity, or your team wants change streams and flexible schema out of the box. The honest comparison: for 80% of 'I need a document DB' use cases, Postgres JSONB + pg_trgm + pgvector is lower-ops and simpler; MongoDB pulls ahead when aggregation pipelines, sharding, or true document variability dominate.
Common Mistakes & Pitfalls
Assuming MongoDB is always faster or that Postgres can't handle JSON well
Check your understanding
Answer these without looking back at the article.
- What's the difference between `jsonb_ops` and `jsonb_path_ops` GIN index classes?
- How does MongoDB's `$lookup` actually execute and why is it slow?
- When does Aurora Limitless Postgres make MongoDB sharding unnecessary?
- How do you replicate MongoDB change streams with Postgres logical replication?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.