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"...

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.

Yeah, the original title was "Show HN: OSS PostgreSQL RDS with Supabase,PostgresML,Vector,HA,PITR,Monitor,&100+ Extensions" ... now auto-renamed without the "RDS" part...

Supabase and PostgresML have been introduced in the latest release. At this juncture, they are in a prototype stage, aiming to expand the functionalities' spectrum.

The RDS part and most extensions have served as production tools for us for a long time.

Imagine a realm where a myriad of extensions can freely interlace, conjuring a synergy where 1+1 transcends 2 within the PostgreSQL ecosystem.

Given that all extensions are optional, bundling them all together poses no harm to the stability of the core part.

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.

If all 150 extensions are installed simultaneously, It's definitely a nightmare. Luckily they are all optional components.

These extensions are pre-packed and included in the local yum repo, which can be enabled by configuration. Only core extentensions are installed by default, which are: pg_repack, wal2json, postgis33, timescaledb, citus, pgvector. And the only extension activated (`CREATE EXTENSION`) by default is pg_repack.

The AGPLv3 is infected by the Grafana, MinIO and citus.

https://github.com/Vonng/pigsty/blob/master/docs/PGSQL-EXTEN...

I used to be a PostgreSQL DBA, and I have just overthrown my own job with my own automation work: https://pigsty.cc / https://github.com/Vonng/pigsty

I think DBA will finally transform to DA: Data Architect, Data Admin, Data Analyst. As for Data'Base' Administration, there are going to be more and more tools, SaaS, and PaaS to eliminate thosea dmin work...