When your Postgres schema is just SERIAL plus JSONB and vibes

Sure, it ships to prod fast - right up until the BI team asks for a LEFT JOIN on a key buried three levels deep in that JSONB column

After 15 years of arguing about normalization forms and foreign key constraints, we've finally achieved enlightenment: every table is just a key-value store with extra steps, and PostgreSQL's JSONB is just MongoDB with ACID compliance and better query planning

Ah yes, the 'two types' approach to PostgreSQL: one for when you need to know what something is (SERIAL), and one for when you've given up trying to predict the future (JSONB). It's the database equivalent of 'I'll organize this later' - except 'later' never comes, and now your entire product catalog lives in a JSON blob with no schema validation. Sure, it makes migrations trivial, but wait until you're writing WHERE clauses that look like 'data->>'nested'->'property'->>'value' = 'something' and your query planner is crying. This is what happens when you let a startup's 'move fast' mentality design your data model - you end up with a relational database cosplaying as MongoDB, and your DBA is somewhere writing a 47-slide deck titled 'Why We Need to Talk About Normalization.'

Postgres: 50+ types for the DBA, SERIAL + JSONB for the dev who ships features faster than schemas evolve

Nothing says relational like id SERIAL and a 300KB JSONB - congrats, you built a document store with ACID invoices and zero foreign keys

Nothing says “future-proof architecture” like id SERIAL and a JSONB column named data - right up until analytics asks for a JOIN and you realize you’ve reinvented EAV with a GIN index and quarterly backfills