Show HN: Pglayers – PostgreSQL extensions as stackable Docker layers
1–10 of 12 posts
Re: Show HN: Pglayers – PostgreSQL extensions as stackable Docker layers
#2Feedback - On your website consider adding a QuickStart for Docker Desktop too.
As you are pitching this at the less technical? and many of them won't use command line but will be using the GUI.
And also, maybe spend a few dollars on a pglayers domain name rather than using a GitHub one.
Re: Show HN: Pglayers – PostgreSQL extensions as stackable Docker layers
#3I need exactly something like this!
Gonna look into it. Thanks!
Re: Show HN: Pglayers – PostgreSQL extensions as stackable Docker layers
#4Nice work. Are you planning to add pgvectorscale?
Re: Show HN: Pglayers – PostgreSQL extensions as stackable Docker layers
#5Are you aware of extension_control_path? [0] Since PG18 it allows specifying multiple non-$system directories for extension control paths, which makes it easier to adopt composable patterns of extension bundling with immutable images.
CloudNativePG uses this for its Image Volume Extensions feature [1]. A lot of the CNPG team worked on contributing this to PG core because previously the only alternative was baking “God images” at build time (“-full” in this readme) with all extensions in them.
Now with the extension_control_path GUC, it’s possible to “attach” extensions as container volumes at runtime, without rebuilding the image of the container. Maybe you can adopt a similar approach in pglayers.
[0] https://postgresqlco.nf/doc/en/param/extension_control_path/
[1] https://cloudnative-pg.io/docs/1.30/imagevolume_extensions/
Re: Show HN: Pglayers – PostgreSQL extensions as stackable Docker layers
#6Good job and very essential design!
> FROM postgres:17 > > COPY --from=ghcr.io/pglayers/pgx-pgvector:17 / / > COPY --from=ghcr.io/pglayers/pgx-pg_cron:17 / / > COPY --from=ghcr.io/pglayers/pgx-postgis:17 / /
I like the way you've solved this!
Re: Show HN: Pglayers – PostgreSQL extensions as stackable Docker layers
#7This is fantastic, i was thinking of something just like this
Re: Show HN: Pglayers – PostgreSQL extensions as stackable Docker layers
#8Good job and very essential design! > FROM postgres:17 > > COPY --from=ghcr.io/pglayers/pgx-pgvector:17 / / > COPY --from=ghcr.io/pglayers/pgx-pg_cron:17 / / > COPY --from=ghcr.io/pglayers/pgx-postgis:17 / / I like the way you've solved this!
Yes, I thought this approach should work, but why nobody has done it. The only real issue is file collisions, which I test for aggressively. So far, I've only found a few minor cases that I either worked around or reported to the relevant projects (e.g. some projects package the extension with a generic README.md file) instead of an extension-specific one.
One surprising benefit that I hadn't considered when implementing this is that when I add new extensions or update existing ones, users only need to update the affected layers. As a result, update times are minimal.
Re: Show HN: Pglayers – PostgreSQL extensions as stackable Docker layers
#9Are you aware of extension_control_path? [0] Since PG18 it allows specifying multiple non-$system directories for extension control paths, which makes it easier to adopt composable patterns of extension bundling with immutable images. CloudNativePG uses this for its Image Volume Extensions feature [1]. A lot of the CNPG team worked on contributing this to PG core because previously the only alternative was baking “Go…
Oh that's excellent. Thanks for sharing. I was not aware at all I cam going to take a look at it.
Re: Show HN: Pglayers – PostgreSQL extensions as stackable Docker layers
#10Feedback - On your website consider adding a QuickStart for Docker Desktop too. As you are pitching this at the less technical? and many of them won't use command line but will be using the GUI. And also, maybe spend a few dollars on a pglayers domain name rather than using a GitHub one.
Good ideas, thanks. My target audience is both less technical and technical users who don't care about the low level details of databases but just want to run their code that uses the db extensions without the need to learn about the internals of the database to be able to use them.