For the extension part, maybe. we only use very limited extensions in production: PostGIS, TimescaleDB, and PGVector will suffice for most cases, plus pg_repack, pg_cron, and wal2json for maintenance.
The core/RDS part (HA/PTIR/IaC/Monitor) is quite robust, which has served our 25000 core deployment for 3 years+ and survived dozens of hardware failures.
It runs on or depends on so many disparate software packages that each comes with their own versioning strategy, security model, etc.
Usually when you install a package in a linux distro either the distro or the package maintainer of the package you install is responsible to ensure it keeps working (with varying levels of effort depending on distro, support strategy, etc...).
With these sort of amalgamation packages that becomes weird. Nobody is responsible and its built with many parts that never tested new versions in that configuration.
You need to either understand what you run or understand who you delegated that understanding to.
This is true for individual packages and even more for amalgamations like this.
In most of these amalgamations you delegated it to nobody and you don't realize until it breaks and you cannot fix it.
For frequently used extensions such as PostGIS, TimescaleDB, Vector, Repack, etc., it can be assured that they function together as expected.
Regarding other extensions, they are only guaranteed to be installed and `CREATE` without error.
I think all the additional layers are the issue for me. There's a lot of moving pieces here that should each be integration tested independently rather than included all together.
