[dewey]

There's nothing wrong with storing json in your database if the tradeoffs are clear and it's used in a sensible way.

Having structured data and an additional json/jsonb column where it makes sense can be very powerful. There's a reason every new release of Postgres improves on the performance and features available for the json data type. (https://www.postgresql.org/docs/9.5/functions-json.html)

[marcosdumay]

> There's nothing wrong with storing json in your database if the tradeoffs are clear and it's used in a sensible way.

Of course. If there was, postgres wouldn't even support it.

The GP's rant is usually thrown against people that default into json instead of thinking about it and maybe coming up with an adequate structure. There are way too many of those people.

[VectorLock]

Rigid structures and schemas are nice, but having document oriented data also has its advantages.

[tuatoru]

> having document oriented data also has its advantages.

As the VC said to the founder who wanted to do things the naive way: "well, I've seen quite a few people try that over the last few decades. It'll be interesting to see if you can make it work this time."

[VectorLock]

If you haven't seen document oriented data work you haven't been looking very hard.

[inkeddeveloper]

And so are document storage databases.

[xwolfi]

It cant be. Json has a huge structural problem: it's an ASCII representation of a schema+value list, where the schema is repeated with each value. It improved on xml because it doesn't repeat the schema twice, at least...

It's nonsensical most of the time: do a table, transform values out of the db or in the consumer.

The reason postgres does it is because lazy developpers overused the json columns and then got fucked and say postgres is slow (talking from repeated experience here). Yeah searching in random unstructured blob is slow, surprise.

I dont dislike the idea to store json and structured data together but... you dont need performance then. Transferring a binary representation of a table and having a binary to object converter in your consumer (even chrome) is several orders of magnitudes faster than parsing strings, especially with json vomit of schema at every value.

[dewey]

> It's nonsensical most of the time

As usual, it comes down to being sensible about how to use a given tool. You can start with a json column and later when access patterns become clear you split out specific keys that are often accessed / queried on into specific columns.

Another good use case for data that you want to have but don't have to query on often: https://supabase.com/blog/audit

> Yeah searching in random unstructured blob is slow, surprise.

If your use case it to search / query on it often then jsonb column is the wrong choice. You can have an index on a json key, which works reasonably well but I'd probably not put it in the hot path: https://www.postgresql.org/docs/current/datatype-json.html#J...

[b0ti]

Couldn't agree more. Not to mention timestamps that JSON simply doesn't handle and is essential for event data. The raijin database has an clever approach to solving the schema rigidity problem: https://raijin.co