Vonng

6 ms·

31.
by 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.
32.
by Vonng 3y ago
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...
33.
by Vonng 3y ago
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 u
34.
by Vonng 3y ago
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
35.
by 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&#x
36.
by Vonng 3y ago
If all 150 extensions are installed simultaneously, It's definitely a nightmare. Luckily they are all optional components.
37.
by Vonng 3y ago
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 on
38.
Show HN: Pigsty – Free RDS Alternative(github.com)
103 points by Vonng 3y ago|50 comments
39.
How about an open-source RDS alternative for PostgreSQL?
4 points by Vonng 4y ago|0 comments
40.
by Vonng 4y ago
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 Arch