Vonng

you're right, OpenTofu forked from the last MPL version of Terraform, not BSL. My mistake — I'll correct the post.

Author here.

• This is translated from my original Chinese post. I used Claude to polish the English — not a native speaker. Fair criticism on the LLM-ese; I'll tighten it.

• This fork exists because MinIO is a production dep in my PG distribution (Pigsty) and I needed working binaries + CVE patches. It's primarily for my own use; sharing it because others may have the same problem.

• We're deliberately conservative — no new features, just a drop-in replacement that behaves like the last OSS release with the console restored. Early commits will look thin.

A minio community fork with admin console back, CI/CD pipeline for Docker/RPM/DEB packages.

Author here. The post here is a 3rd-party translation and may drifts from original wording in a few spots. Azure and OpenAI sent me some corrections today, so I published an updated English version myself here: https://pigsty.io/blog/db/openai-pg/

BTW for anyone who interested, I've packed pg_search and vchord_bm25 extension RPM/DEBs https://pigsty.io/ext/fts/vchord_bm25 https://pigsty.io/ext/fts/pg_search In case anyone want to benchmark by themselves. ;)

There are 351 available rpm/deb postgres extensions which can do really a lot of things: https://ext.pigsty.io/#/

I fully support ParadeDB's decision. For an open-source software company, AGPLv3 + Dual License is the most sensible choice.

If you go with Apache 2.0, you're literally doing free work for cloud vendors.

I've set up a supplementary APT/YUM repository, which builds on the official PGDG offerings. This includes 326 extensions for EL distros and 312 for Deb distros, encompassing 121 RPM packages and 133 DEB packages.

These packages support PG16 extensions across Ubuntu 22.04, Debian 12, EL8, and EL9. My efforts have been particularly focused on align OS-specific extensions across the major Linux distributions to ensure a consistent feature set.

For those who are interested, you can browse the PostgreSQL extension catalog here: (https://pigsty.io/docs/pgext/list/). Additionally, I've maintained a public Yum/Apt repository hosted on Cloudflare: https://pigsty.io/docs/pgext/usage/repo/

I'm keen to hear your thoughts and would greatly appreciate any feedback from those who have utilized these extensions.

Why not continue to use rpm/apt for building and packaging? You can reuse these packages in the Dockerfile and the image, but not the other way around.

RDS is like 4~13x than EC2 on AWS, 2.3x than EC2 on aliyun. https://pigsty.io/blog/cloud/rds/

But The real cost lies on EBS, which is around 60x ~ 200x than local NVMe SSD. https://pigsty.io/blog/cloud/ebs/

https://pigsty.io/blog/cloud/bonus/

How about: PostgreSQL tuned (x47). PostgreSQL + Hydra Extension (x42) PostgreSQL + ParadeDB Extension (x10.7)

That's true for the kernel, How about extensions such as ParadeDB BM25 https://www.paradedb.com/ + PGroonga https://pgroonga.github.io/ + PG Bigm https://github.com/pgbigm/pg_bigm ?

Patroni has native HA support for citus horizontal cluster since v3. Which means your can create a HA citus cluster as simple as: https://pigsty.io/docs/pgsql/config/#citus-cluster

pg_hint_plan —— Give PostgreSQL ability to manually force some decisions in execution plans. https://github.com/ossc-db/pg_hint_plan

The scale of operation is the crux here. For a modest number of cores, RDS is a congenial choice. However, when you're going to hundreds or, as in our scenario, tens of thousands of cores with PostgreSQL, clinging to RDS is sheer lunacy.

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.

It might require a bit of elbow grease to grasp every component. I'm trying my best to smooth out that learning curve:

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.

Redis is more like a cherry on top. Many applications utilizing PostgreSQL also employ Redis, Gitlab being a notable example, and that includes us as well. Supporting Redis merely involves adding a couple of RPMs and Playbooks, so why not go for it ;)?

You don't need to rebuild the docker image and restart the container to get the extension installed & created.

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.

The title was auto-updated without the crucial "RDS/Distribution" part before "alternative"...