PostgreSQL 17 adds SQL/JSON and faster I/O, but MongoDB still leads some update-heavy JSON tests. Here
What PostgreSQL 17 changes for JSON workloads
PostgreSQL 17 tightens the gap for teams that store and query document-shaped data inside a relational engine. SQL/JSON support makes path expressions, filtering, and projection feel closer to native document work, while I/O improvements reduce the cost of reading and writing larger row and JSON payloads. That matters when your primary model is still relational—orders, users, inventory—but you also keep flexible attributes, event payloads, or config blobs that do not deserve a separate database.
The practical shift is not “JSON is free now.” It is that JSON columns become less of a last resort. You can express more of the access path in SQL, rely on the same transactions and constraints as the rest of the schema, and avoid a second operational stack for many mixed workloads. The cost is still modeling discipline: oversized documents, deep nesting, and unbounded growth inside a single value remain hard to index and update efficiently.
Where MongoDB still tends to win
MongoDB is built around documents as the primary unit of storage and mutation. For update-heavy JSON patterns—frequent partial field changes, write-skewed hot documents, or APIs that treat the whole object as the source of truth—that design often stays simpler and faster in practice. You mutate the document shape you already ship over the wire, without mapping every nested field into SQL expressions or worrying about how a large JSON value interacts with row versions and table bloat.
Benchmark reality checks usually surface this split. Relational engines can look strong on read-oriented JSON queries, joins across structured tables, and mixed analytical filters. Document engines often look stronger when the workload is many small, concurrent updates to flexible structures. If your product’s write path is “patch this nested field thousands of times,” that second case deserves more weight than headline feature lists.
How to read benchmarks without fooling yourself
Vendor and blog numbers almost never match your traffic shape. Before you trust a comparison, map the test to your real access patterns:
- Read vs write ratio, and whether updates are full document replaces or partial field patches
- Document size distribution and how often nested arrays grow without bound
- Need for multi-document or multi-table transactions and strict relational integrity
- Query shapes: point lookups, path filters, aggregations, or joins to normalized tables
- Operational constraints: backups, schema evolution, team SQL vs document skills
A fair test uses representative payloads, concurrency, and indexes on both sides. Microbenchmarks that only insert tiny objects or only run cold-cache scans will overstate one engine and understate the other. Treat published results as a hypothesis to re-run, not a verdict.
Choosing a default for your next service
Prefer PostgreSQL 17 when JSON is secondary to relational data, when you need strong consistency across tables, or when one database for reporting, joins, and documents reduces ops cost. Prefer MongoDB when the domain is naturally document-centric, schemas change often at the edge of the object, and the hot path is frequent JSON updates with little join work.
Many systems land in the middle: keep core entities and money paths in PostgreSQL, and isolate high-churn document stores only where the update profile demands it. The useful takeaway from a PostgreSQL 17 vs MongoDB reality check is not a winner—it is matching storage model to write shape, then validating that choice with a benchmark that looks like production.