PostgreSQL JSONB: when you do not need a separate NoSQL database
Before adding MongoDB or another document store to your stack, it is worth checking what PostgreSQL's JSONB type can already do - and where it genuinely runs out.
The conversation about SQL versus NoSQL databases has been going for almost a decade. In practice, most of the teams I work with do not have a workload that demands a pure NoSQL system. What they have is a relational database with a few tables where the schema changes often or varies between rows. And for that specific problem, PostgreSQL's JSONB column type has been a practical answer since version 9.4.
I am not arguing against document databases. There are genuine use cases for them. But adding a second database technology to a stack carries a real cost, and before paying that cost it is worth understanding what you already have.
What JSONB actually does
JSONB stores JSON as a parsed binary structure, not as a raw string. This means PostgreSQL indexes it, queries into it, and applies standard SQL functions against it. You can write queries like "give me all rows where the config JSON contains "notify": true" without loading and parsing everything in application code.
You get GIN indexes on JSONB columns, which makes lookups inside JSON documents fast enough for most operational workloads. You can mix structured columns and JSON columns in the same table and the same query.
Where this works well
From what I have seen, JSONB is a good fit for:
- Configuration and settings tables where every row has a different shape.
- Event or audit tables where the payload varies by event type but you want transactional guarantees.
- Integration points where you receive external JSON and want to store it with minimal transformation while still querying it.
- Prototyping stages where the schema is genuinely not yet stable.
In each case, the win is keeping everything in one database with one transaction model, one backup regime, one operational team, and one connection pool.
Where it runs out
JSONB is not a replacement for a dedicated document store when:
- You are storing documents that are many megabytes each and need partial updates at the byte level.
- Your access patterns are exclusively document-oriented and no relational joins are ever needed.
- You need MongoDB's particular aggregation pipeline or its native sharding model.
- You have a team with deep MongoDB expertise and zero PostgreSQL expertise.
That last point matters more than people admit. Technology choices have to fit the people operating them, not just the benchmark results.
The decision I actually recommend
Before proposing a new database technology, I ask one question: can the existing PostgreSQL instance handle this with JSONB, and does it stay readable and maintainable? If yes, stay in one system. If the answer honestly is no - and sometimes it is - then bring in the specialist tool.
The cost of maintaining two database technologies is real: two backup strategies, two sets of operational runbooks, two points of failure to monitor, and two knowledge domains your team needs to cover. That cost has to be justified by a genuine requirement, not by a preference for the newer tool.