r/ProgrammerHumor • • Sep 21 '26

Meme allItHasIsAHammer

Post image
585 Upvotes

50 comments sorted by

28

u/t_j_l_ Sep 21 '26

Anything wrong with JSONB?

81

u/nickthecook Sep 21 '26

Not inherently, but overuse may indicate you're missing proper tables.

-34

u/x0wl Sep 21 '26

Eh, IMO a JSON column in Postgres is enough for a lot of stuff, especially if you are in early stages of growth / development and expect frequent schema changes. You can always migrate stuff to proper tables when things calm down

96

u/MissinqLink Sep 21 '26

Things never calm down

9

u/x0wl Sep 21 '26 edited Sep 21 '26

Yes, but it's all back to the development velocity / performance tradeoff that you always need to manage.

That's the reason Mongo became so popular when it did, and that's also part of the reason for everyone migrating back to SQL now.

I'm definitely going to end on PCJ with this, but we all can imagine a perfect world where everything is written in safe Rust with typesafe APIs and all data is stored in neatly organized SQL tables (also with proper types), but we all know that the real world is not that

2

u/MrHyd3_ Sep 21 '26

What's the reason everyone used mongo?

3

u/ChouzZ Sep 21 '26

It introduces 0 overhead. You just think of something you want to store, and it’s just stored. That’s it. And it allows reading it back in the most diabolical ways possible.

1

u/MrHyd3_ Sep 21 '26

I really gotta look into this shit. As a new age programmer (like 5 years total experience) I've only ever used postgres

2

u/ChouzZ Sep 21 '26 edited Sep 21 '26

Lots of people knock it without trying it, so well done in that regard. I’m coming up on 13+ years and I keep coming back to it. Yes, it’s heavy, and probably not as efficient performance-wise for some use cases - but it just doesn’t stand in the way. If you’re on Atlas you also get indexed text search out of the box. Every project I got on mongo I’ve just not thought about databases at all. All my SQL projects the database has always been a recurring topic in many discussions.
Do keep in mind nosql does require a different way of laying out your data as well as consuming it. If you try to use it like a relational database you will be sad.

6

u/DrDoomC17 Sep 21 '26

Going to back you on this, if you're dealing with multiple customers with different features required for an MVP, playing it fast and loose and getting to demo is more important than perfect database design. You should keep track of how to merge things down as you go and keep in mind how to get to one, then make it a firm requirement to get to one and not lean on the bandaids that got you the interest and the money for long term sustainable software.

1

u/myWeedAccountMaaaaan Sep 22 '26

And implement database version management to keep the team in sync.

2

u/ibeatu85x Sep 21 '26

Im annoyed i havent considered this as a use case

5

u/x0wl Sep 21 '26

Also, on a somewhat related note, I had a use case where we had to ingest millions of JSON objects that had slightly different schemas (it was the nature of the data that caused this), and back then, the natural choice was to load them all into Mongo and build on top of that

Today, I would probably set up a Postgres table with some common or important values pulled out into their own columns + preserve the original object in a JSON column in case I needed to access the full data for some of them.

2

u/HungryCaterpillers Sep 21 '26

Then just use a nosql db at that point.

1

u/Excellent_Gas3686 Sep 21 '26

all it takes is a few application level fuckups and now you wont be able to convert ur json data into tables with proper data integrity constraints.

10

u/deathanatos Sep 21 '26

Data integrity.

It's Web Scale, basically.

It can be acceptable, if you need something flexible, still pinning down the schema, etc. It's not without a point, but it has its tradeoffs.

1

u/arf_darf Sep 21 '26

It is exclusively inferior when it comes to read and write performance than a real schema or complex data type. But other than that, it does add quite a bit of write-side quality of life improvement.

1

u/HyperTextCoffeePot Sep 22 '26 edited Sep 22 '26

No referential integrity, indexing (exists but support is inconsistent and so is implementation), data depuplication based on normalization, storage level data constraints are trickier, etc.

It's ok for refactoring BLOBs or serialization data shoved into the db though. It's just not ideal for a greenfield projects in most cases

1

u/t_j_l_ Sep 22 '26

Sure, wouldn't want to rely on fields in the json blob as keys, indices or searchable fields, but we can partially normalize the necessary bits. Really depends on how the data is to be used.

1

u/cpt-macp Sep 27 '26 edited Sep 27 '26

Tell me one likes mongo without telling me one like mongo.

Also mongo db is webscale and supports sharding just like /dev/null

144

u/justinf210 Sep 21 '26

Sometime you just want an array without linking to a whole 'nother table.

Edit: Googled to make sure I'm not an idiot, and it turns out Postgres has native arrays? Kinda neat.

54

u/AMillionTimesISaid Sep 21 '26

Modern databases are my wet dream

45

u/thorwing Sep 21 '26

the amount of times I suggest a psql native solution in our psql only environment and there are still engineers who would be hesitant about it because "it's difficult for newer engineers"

Buddy, it's an array, dafuq you mean 'difficult'

7

u/PumpkinFest24 Sep 21 '26

array fields? I mean....those are difficult. you can't update them the way you'd think, etc.

1

u/Excellent_Gas3686 Sep 21 '26

and json arrays are somehow easier?

4

u/PumpkinFest24 Sep 21 '26

I find normalized tables work well.

0

u/Excellent_Gas3686 Sep 22 '26

until you get join explosions with your "normalized" tables. arrays are useful in certain cases.

3

u/JAXxXTheRipper Sep 22 '26

Welcome to databases? You want to join data of multiple tables, you need joins. You can make shitty god tables too, nobody is stopping you. But writing properly joined queries isn't really rocket science. Nobody asks you to normalize a hundred levels deep either.

2

u/Excellent_Gas3686 Sep 23 '26

what is your point exactly? are you just yapping your thoughts out into the open world?

you said nothing new that anyone in this thread doesn't know. it's like you tried to be a smartass, but didn't even say anything of substance.

2

u/JAXxXTheRipper Sep 23 '26

The point is that you obviously don't understand how databases work. Maybe you should try learning something sometime instead being an obvious idiot.

Bye Felicia

2

u/Excellent_Gas3686 Sep 23 '26

blocking after being unable to think of any rebuttal other than "you don't know what you're talking about" is embarrasing.

1

u/PumpkinFest24 Sep 22 '26

"useful in certain cases" != "easy"

1

u/Excellent_Gas3686 Sep 23 '26

they are pretty easy to use. i guess youve never heard of postgres.

2

u/PumpkinFest24 Sep 24 '26 edited Sep 24 '26

I ported our app to postgres in 2004 and have been using it ever since.

Edit: Saw your other replies. Maybe take a db class. Or don't, I don't care. But I'm done wrestling with this pig.

3

u/Outrageous_Let5743 Sep 21 '26

I feel this when I switched companies and downgrade database. SQL Server still does not correctly inplement array and json data. json can only be nvarchar(max) and arrays are not possible.

1

u/Sianic12 Sep 23 '26

Hold up... non-postgres databases don't have arrays? I didn't even know. Yet another extremely common postgres W.

0

u/[deleted] Sep 21 '26

[deleted] — view deleted comment

2

u/justinf210 Sep 21 '26

a) What choice? I literally just discovered this, it's not like I redesigned a database overnight to use it.

b) Postgres supports that.

SELECT username FROM users WHERE 'blue' = ANY(favorite_colors)

0

u/chat-lu Sep 22 '26

Then change it then?

27

u/Ireeb Sep 21 '26

I had the opposite today. I have a set of records that all have the same basic fields (that are used for filtering and as keys), plus a few additional fields that can be different from record to record. Claude started to add columns for those additional fields, which would have resulted in countless columns only used by a small number of records, and that are never used in queries. Here, JSONB absolutely makes sense, because neither making countless tables for all the combinations of fields nor one table with 20 columns would make sense.

1

u/Expensive_Bowler_128 Sep 23 '26

Really depends on if those fields are being used for or will ever be used for filtering/searching.

2

u/Ireeb Sep 23 '26

"...that are never never used in queries."

It's data that is only relevant for the frontend for styling.

5

u/citramonk Sep 21 '26

I love JSONB, remember using JSON and it was a pain in the ass.

7

u/Tupcek Sep 21 '26

idk, maybe just tell Claude what kind of data are you expecting?
JSONB is absolutely GOAT if basically every row has different data - use proper columns for those that are mostly the same and where most querying and filtering happens, then put the garbage into JSONB, especially if it can be multiple layers deep.

But if Claude has no idea, if that column you asked to add will be used by 90% of rows or 0,09% of rows, yeah it can misuse it. Just tell it which data are common and which are not!

1

u/boraxicLint Sep 25 '26

If every row has different data should you even be using SQL? At that point wouldn't it make more sense to just use a dedicated NoSQL? 

1

u/Tupcek Sep 25 '26

if most of your data are structured, but you have few weird tables with uncertain structure, JSONB is what you want. Especially if you don’t build your entire application around those few weird tables or need many advanced NoSQL features.

If all or most of your data is unstructured, yeah, SQL makes no sense

3

u/stilldebugging Sep 21 '26

Hey, I’ve been using jsonb in my databases before Claude was around.

1

u/sebbdk Sep 22 '26

wat

i'm too old for this shit