Nice explanation. I totally agree with that fact that we should not use Postgres as Document DB just based on JSONB. If you need extreme read or write scale on documents or your access patterns are more likely document-oriented then never use it as document db.
But there are some libraries like Marten which uses Postgres as document db (mainly because of JSONB), which is mainly used in Event Sourcing patterns. And it is one of the best library to use for this kind of scenario.
thanks for your comment, totally agree, the key point is use case.
JSONB is powerful, but that doesn’t automatically turn PostgreSQL into a full-fledged document database. If your workload is heavily document-oriented or you need massive read/write scaling, a purpose-built document DB will always make more sense.
Will write more on this in upcoming days :) happy to collaborate.
Phenomenal articulation of a nuance that trips up so many engineers moving between database paradigms.
The btree expression index guidance is particularly valuable. I've seen teams default to GIN indexes on JSONB columns because it feels like the "proper" NoSQL approach, then wonder why their query performance degrades as data scales. The reality is that if you're consistently filtering on the same 1-3 keys, that btree index on the extracted value gives you exactly the performance characteristics you'd get from a regular relational column, without the schema rigidity.
One thing worth emphasizing: the 80/20 model you describe (80% structured, 20% flexible) is aspot-on heuristic for when JSONB makes sense. The danger zone is when teams use JSONB as an escape hatch for poor schema planning. I've debugged systems where critical business logic was buried in JSONB fields precisely because the team wanted to avoid migrations, and the maintenance cost compounds fast when you need to refactor queries across thousands of variable-structure JSON blobs.
Thanks for the insight! Totally agree teams often jump to GIN for JSONB when a simple btree expression index fits the actual access pattern way better.
And yes, the 80/20 rule is key that i always say to our end customers whenever i deal with Sev 1 that end up on this situation; JSONB shines when used intentionally, not as an escape from proper schema design.
Nice explanation. I totally agree with that fact that we should not use Postgres as Document DB just based on JSONB. If you need extreme read or write scale on documents or your access patterns are more likely document-oriented then never use it as document db.
But there are some libraries like Marten which uses Postgres as document db (mainly because of JSONB), which is mainly used in Event Sourcing patterns. And it is one of the best library to use for this kind of scenario.
So overall it depends upon your use case.
thanks for your comment, totally agree, the key point is use case.
JSONB is powerful, but that doesn’t automatically turn PostgreSQL into a full-fledged document database. If your workload is heavily document-oriented or you need massive read/write scaling, a purpose-built document DB will always make more sense.
Will write more on this in upcoming days :) happy to collaborate.
Phenomenal articulation of a nuance that trips up so many engineers moving between database paradigms.
The btree expression index guidance is particularly valuable. I've seen teams default to GIN indexes on JSONB columns because it feels like the "proper" NoSQL approach, then wonder why their query performance degrades as data scales. The reality is that if you're consistently filtering on the same 1-3 keys, that btree index on the extracted value gives you exactly the performance characteristics you'd get from a regular relational column, without the schema rigidity.
One thing worth emphasizing: the 80/20 model you describe (80% structured, 20% flexible) is aspot-on heuristic for when JSONB makes sense. The danger zone is when teams use JSONB as an escape hatch for poor schema planning. I've debugged systems where critical business logic was buried in JSONB fields precisely because the team wanted to avoid migrations, and the maintenance cost compounds fast when you need to refactor queries across thousands of variable-structure JSON blobs.
Thanks for the insight! Totally agree teams often jump to GIN for JSONB when a simple btree expression index fits the actual access pattern way better.
And yes, the 80/20 rule is key that i always say to our end customers whenever i deal with Sev 1 that end up on this situation; JSONB shines when used intentionally, not as an escape from proper schema design.
Appreciate you sharing this!