Show HN: pgxman – npm for Postgres extensions (pgxman.com)
Installing and updating Postgres extensions is an uphill battle. You're left searching for the right build tools and grappling with often unclear and incomplete compiling instructions to even try one out. But with pgxman, we've streamlined the process to one simple step: pgxman install [extension name].
For example, to build parquet_s3_fdw manually, you'd need to:
1. Download the parquet_s3_fdw source code;
2. Figure out how to build it by looking at README. When unclear, look at the source code how to build it. The README of parquet_s3_fdw says it needs libarrow, libparquet & aws_sdk. Readme doesn’t say where to get them.
3. Make sure all dependencies are available to build the project. Either install them from apt, if available, or build them manually if not. For parquet_s3_fdw aws_sdk has to be built manually — it’s not available in any apt repos
4. Build the extension targeting the correct OS, CPU architecture and Postgres version.
5. Determine and build to the right path /usr/lib/postgresql/15/lib - otherwise, Postgres wouldn’t be able to find them.
6. Repeat across all relevant Postgres instances. Hopefully, these Postgres versions are recent or else you’ll have to update postgres, set maintenance window, etc.
* Added friction: Since parquet_s3_fdw is not designed to use in a cloud environment, and we forked it to make changes to make it possible to use.
Using pgxman, you can just do:
pgxman install s3_parquet_fdw
pgxman integrates with your system package manager, ensuring the correct versions are installed without extra packages from any shared dependencies between extensions. pgxman’s automated build system creates [APT] packages for each Postgres version, platform, and OS supported by the extension. Extensions are built from a “buildkit” formula, written in YAML, and are contributed through GitHub.To install pgxman, you can do
brew install pgxman/tap/pgxman
or, if you don't mind pipe-to-shell, curl -sfl https://install.pgx.sh | sh -
If you'd like to learn more, we have an extensive blog post here: https://www.hydra.so/blog-posts/the-design-of-postgres-exten....
24 comments
[ 2.9 ms ] story [ 70.8 ms ] thread* PGXN (https://pgxn.org/ - the original Postgres community extension repository, though more "old school")
* Trunk by Tembo (https://github.com/tembo-io/trunk - very similar to pgxman, but using the more liberal Postgres BSD-style license)
Additionally its important to mention that many popular extensions are already packaged as part of the Postgres YUM and Apt repositories (https://wiki.postgresql.org/wiki/Apt and https://yum.postgresql.org/).
I would generally recommend using the upstream repository packages directly, since they are tested/updated with each major release, and their maintainers are proactive in reaching out to extension maintainers that need to update their extension due to upstream code changes.
https://supabase.com/blog/dbdev
Not all extensions have an upstream repository and built debian/yum packages. At Hydra, we test all published in https://github.com/pgxman/buildkit which is available from our registry.
Thanks for mention :)
Can I use this in any way without a global system state? Like with https://github.com/zonkyio/embedded-postgres-binaries or similar that don't have a global install? Or with a distro that supports multiple versions/instances of postgresql?
On Ubuntu/Debian, Postgres doesn't typically work this way, so it's not the way that pgxman works. pgxman works on top of the existing `postgresql` packages and with the existing package manager (apt) in order to install extensions -- which is also how it handles runtime dependencies, whether libraries or even other extensions.
So, that said, we have a container feature I could see using to effectively isolate for a single project. Right now there is only one single "global" container (per Postgres version) that pgxman will manage for you, but this is just a MVP of this feature. I could definitely see something like `pgxman c dev` or similar which will read a local pgxman pack file (pgxman.yaml) in your project and boot a "local" Postgres for you just for that project.
The pgxman pack is already a thing and is how the local container config is maintained, but we haven't tied it together in the way described above... yet. For more on both pgxman pack and the container feature, check out our docs.
I know 100% is full cpu usage, but what does 700% mean?
What an incredibly good idea.
Edit: Looks like there is some existing (partial) competition from pgxn: https://manager.pgxn.org/about
Is pgxman an extension manager for Postgres like apt for Debian?
Does it work with the postgres Docker image? Can I:
We only support apt for now but plan to support other package managers in the future. It works with existing Postgres apt packages, we recommend using PGDG but the default system packages on Debian/Ubuntu work as well.
> Does it work with the postgres Docker image?
yes, in fact this how our `container` feature works. https://docs.pgxman.com/container
Could these packages be put in a repository online, so that they can be installed without using pgxman?