[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/case/ - Case Studies

Success stories, client work & project breakdowns
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1793263156365.jpg (180.01 KB, 1024x1024, img_1793263146786_mfealczv.jpg)ImgOps Exif Google Yandex

f2ec2 No.2399

been looking at some recent implementations where teams are dumping raw json into postgres just because it's easy. honestly it's a disaster for any real reporting once you hit a certain scale. i saw a setup last week that was basically crawling through nested arrays just to find a single timestamp. it's fine for a quick prototype but never do this for production metrics. you end up with queries that take minutes instead of milliseconds. the overhead on the cpu is massive when you're trying to parse deep objects during every aggregate. we had to rewrite an entire dashboard because the jsonb indexing wasn't hitting the right keys. i've learned the hard way that schema enforcement saves lives. you can always add columns later if you know what you're looking for.
>it's easier to just dump everything in a blob and figure it out later

that mindset is exactly how you end up with a database that's impossible to maintain. anyone else still stuck dealing with massive jsonb blobs in their analytics queries?


[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]