Comment by ddxv
I've built myself a few problems that I haven't fixed yet:
Many materialized views that rely on materialized views. When one at the bottom, or a table, needs a changed all views need to be dropped and recreated.
Using a warm standby for production. I love having a read only production database, but since it's not the primary, it always feels like it's on the losing end of the system. Recently upgraded to Postgres 18 and forgot that means I need to rm rf the standby and pg_basebackup to rebuild... That wasn't fun.
I'd like to call views, triggers, and integrity constraints antipatterns.
Your code should handle the data model and never allow bad states to enter the database.
There's too much performance loss and too many footguns from these "features".