Given that all extensions are optional, bundling them all together poses no harm to the stability of the core part.
Speaking of which, why isn't this project delivered as a Helm chart?
https://doc.pigsty.cc/#/PGSQL-ARCH?id=component-overview https://doc.pigsty.cc/#/PGSQL-ADMIN https://doc.pigsty.cc/#/SECURITY https://doc.pigsty.cc/#/ARCH
However, when it comes to getting it up & running, the process is pretty straightforward, and the outcome is leagues ahead compared to running the kernel in the raw way.
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.
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.
Curious if there are runtime downsides to having so many extensions installed
The AGPLv3 is infected by the Grafana, MinIO and citus.
https://github.com/Vonng/pigsty/blob/master/docs/PGSQL-EXTEN...
It's the places that go "Ewwww... AGPLv3!" that you have to wonder about.
> Battery-Included PostgreSQL Distribution, with 150+ powerful extensions!
Wow, you weren't kidding.
RDS is a managed service. This is a code repo. It is useless until you deploy it at which point... it's no longer free. Then you have to manage it yourself and deal with the overhead yourself.
This is like saying I can fire my gardener because you have a free gardener alternative, and then handing me a pair of scissors. I now have all the problems that I paid the Gardener to solve.
Likewise, we pay AWS to manage all the headaches that deploying this would introduce. And trust me, if you are running databases at scale in production, then RDS feels very affordable considering the problems it solves.
I was the designated gardener to tackle this: architecting and managing a PostgreSQL deployment with 25K cores and 3M TPS. We've been shelling out a cool $1M annually, covering the whole thing - hardware, software, and DBAs. Meanwhile, the toll for RDS is an astronomical tenfold of our current expenditure, yet it comes with a lesser degree of availability and a starkly crippled observability and other stuff.
And, I haven't found any Postgres docker image with all the extensions I need: you can reuse the RPM in dockerfile to build your own image, which always has to be done somewhere.
Is this intended as a prototyping tool?
The RDS part and most extensions have served as production tools for us for a long time.
This HN thread is already full of people saying "this looks brittle", "maintenance nightmare", &c. because the README spends so long trying to convince you that this product is a huge, multifaceted kitchen sink. People want simplicity, noone is looking for a plethora of things they need to run, why would you ever try and sell anything as that?
Most of the "features" they enumerate are either:
- optional pg extensions that are available in normal pg by default
- orchestration software that one might use to deploy HA pg clusters in a distributed / k8s type env anyway (i.e. it's not extra, it's just your underlying infra templates - e.g. Terraform, Patroni, &c.)
The only thing I really see there that is "not-really-needed-kitchen-sink-extras" is the observability stack (grafana, loki, &c.)
Most folks should use RDS etc. (Yes, it's expensive and has limitations.)
If you need or want to self-host, you need to understand every moving part and how they fit together. The effort and knowledge required to assemble your own setup are essential, and outsourcing them to a magic bundle would be a mistake.
