3 ms·

This looks very very fragile. If all of this works, great job though.

by nik736 3y ago

Vonng 3y ago
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.
fastball 3y ago
How does it look fragile?
- mplewis 3y ago
  The project lists dozens of extensions that it supports. The likelihood of one of them not working properly is very high.
  - Vonng 3y ago
    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.
    - SteveNuts 3y ago
      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.
- SahAssar 3y ago
  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.

This looks very very fragile. If all of this works, great job though.

by nik736 3y ago

This looks very very fragile. If all of this works, great job though.

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.

fastball 3y ago

How does it look fragile?

mplewis 3y ago
The project lists dozens of extensions that it supports. The likelihood of one of them not working properly is very high.
- Vonng 3y ago
  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.
  - SteveNuts 3y ago
    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.
SahAssar 3y ago
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.