Jsonb is well known, but so so slow compared to doing aggregations with mongodb. For simple use cases yes, you don't need that performance, but by simple I mean: your personal blog. In 12 years I have never encountered any enterprise app where jsonb was a good choice in the long run.

Thx this is first time I'm hearing about jsonb. very cool.

pretty epic seeing someone call out most nosql hype like this - ever find yourself picking tech just to avoid migrations, or is it usually about performance?

I’ve used JSONB that way for tons of event logs and custom app configs - it honestly feels like cheating sometimes. What’s the most complex thing you ever modeled in JSONB?

While jsonb is great, just from the examples I see the overuse of the column type.

User Preferences/Settings: Every user wants different things. Don't create 50 boolean columns.

Create a preferences table with an id and the name of preference, and have a pivot table with the ids of preferences and user ids.

Product catalog and form submissions, a similar solution.

I see more a shortcut to not do data normalization, than splitting document structured data from relational data.

While they are pushing you to their Atlas solution, there is still the freecommunity server. No need to pay, just a willingness to set it up.

From the post you made i see you had a good experience with jsonb, and that is great. The problem I have that the information you provide is skewed by the experience. it is a trap I fell for many times, so I'm as fallible as you. Over time I learned all tools have their good and bad sides, and we have to use them for their good sides.

That is new to me! Really cool stuff! thanks for sharing!

This is really great article. A gem in a pile of AI crap usually posted on DEV.to nowadays.

And I agree that JSONB brings the best of both worlds. Moved from MongodDB two years ago using exactly the same strategy. We also combine this with static JSON files stored in buckets storage.

The big plus is also full text search. This cannot be achieved in MongoDB but is easily done with JSONB.

This approach works only on very small databases because indexing this structure is more challenging and limited compared to document databases like MongoDB. Using UUIDv4 for IDs can be harmful (UUID PRIMARY KEY DEFAULT gen_random_uuid()), as these IDs are scattered throughout the table, which can negatively impact performance, especially with shared buffer caches and B-Trees.
But there is worse with the single JSONB. I've written a series on the pain points people experience when using PostgreSQL as a document database. The lack of Index Only Scan, the lack of range or sort covering with GIN index, the read and write amplification:dev.to/mongodb/no-hot-updates-on-j...

Brilliant deep dive! This perfectly showcases how versatile and powerful Postgres + JSONB can be for modern app needs. A great reminder that sometimes one optimised tool can replace a stack of complexity. Thanks for sharing!

This reminds me of back in the day when XML support was added to MSSQL, now we could store SOAP responses directly into our columns, it was magic. Looking back, it was bloated and needed wizardry to parse elements. In fact i see a circle, soap+xml, rest+json, grpc+protobuf and now json-rpc+json

Click baity title with no real heavy loaded aggregations example, nosql DBS shine best with heavy and complex searches. Also as others have stated what you are proposing here it's a trap that leads to no data normalization. In short it might seem attractive at the start, a nightmare at the end

Mongodb can handle 65536 concurrent connections by default..postgresql 100, if you increase it, it affect performance.

Sharding is hard to implement in postgresql but in mongodb its super easy.

Absolutely brilliant breakdown.
As a developer who's worked extensively with both MongoDB and Postgres, I couldn't agree more — jsonb is criminally underrated. The combination of SQL power, schema flexibility, and indexing makes it a true Swiss army knife, especially for event logs, dynamic metadata, and hybrid schemas.
Also admire how you structured the migration Strategy — I’ve done similar for moving audit logs and form builders into Postgres, and performance actually improved once we tuned GIN indexes correctly.

I think PostgreSQL isn't just relational anymore — it's relational with superpowers. ✨

"Maybe I should just use MongoDB," you whisper to yourself.

Then you slap yourself into the face and get back to use a proper schema and relations in your relational DB. :)

Great Post. Have you benchmarked query performance between your Postgres **JSONB **model and the previous Mongo setup? Would love to know if Postgres held up under load.

I think JSONB works well for simple use cases like user or tenant settings that are mostly static - data that rarely changes and doesn't need aggregation or complex queries.

Sounds great. SQL & NoSQL together. 👌🏼👌🏼

I have been seeing jsonb all times, took it for just a json collector type. But you gave me beautiful insight into it value.. Thank you very much

Been doing this for over 5 years. Really handy and gets the job done.