Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's more "what one tool can do everything", not that its ideal. Like why people use Microsoft Teams even though its terrible.

The relational model and sql force us to simplify our data models too much by eliminating relationships or just not dealing with them.

Think about a nested json blob from some web service api and storing it in SQL in normalized tables. No one is going to do that. Everything just becomes a denormalized mess and everything is hacked around it.

Instead of modeling things in the proper way, most of the world's data is modeled in a way so that we don't have join explosions in sql queries because they look scary. Data pipelines become these scary batch transformations where data is dumped somewhere else without anyway to trace back where it came from.

I encounter so many end-user applications and systems where you wonder: "why couldn't they allow a list of items here instead of a single box" or "why can't this reference this other thing".



I think you’re responding to the general idea of a relational database, not Postgres, and definitely not what’s in the article (DR;CA).

Postgres has built in data types and functions that allows it to work with unstructured json documents, like you would use in MongoDB.


That feature is definitely part of why it's still so relevant. The hstore approach wasn't nearly enough when it was all PG offered.


"Work with" != "work well." GIN indices aren't the same as B+tree, and even then, you'll have to decide / know about jsonb_path_ops vs. the default operator class. Or you just accept sub-optimal performance, I suppose.

The lack of a rigid schema makes it super fun as well. Does this attribute exist in this row? Who knows! Maybe there's a long-forgotten version lurking, waiting to be retrieved, that will utterly bork the calling app.


people do that with JSON way too often...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: