Feature Request: nix packages support

[soulwhisper]

Thank you for maintaining the valuable PostgreSQL packages and extensions in this repository! To expand accessibility and reliability for modern deployment workflows, we request official support for Nix packaging (including a dedicated nix branch).

Why Nix? Key advantages:

• Unified packaging workflow
  Single Nix expression → deb, rpm, tarballs, Docker images, and Nix packages
  Eliminates per-format maintenance overhead
• Reproducible environments
  Cryptographic hashes guarantee identical builds across all systems
• Atomic upgrades & rollbacks
  Instantly revert failed deployments with zero downtime
• Multi-version coexistence
  Run parallel PostgreSQL/extension versions without conflicts (ideal for CI/CD)
• Declarative configuration
  Define entire stacks in version-controlled .nix files
• Cross-platform support
  Consistent behavior across Linux/macOS

Requested Implementation

Component	Purpose
nix branch	Host Nix expressions versioned with main releases
default.nix	Base package definition
release.nix	Cross-format build pipeline (deb/rpm/Nix/etc.)

Impact

• Single source-of-truth for all package formats
• Reduce maintenance by 50-70% (no separate spec/dsc files)
• Serve Debian/RPM users + Nix ecosystem simultaneously
• Enable CI/CD parity from dev to production

I am happy to:

• Provide implementation guidance
• Contribute draft Nix expressions
• Test initial builds

Example expression from nix-community for discussion:

{
  fetchFromGitHub,
  lib,
  postgresql,
  postgresqlBuildExtension,
}:

postgresqlBuildExtension (finalAttrs: {
  pname = "pgvector";
  version = "0.8.0";

  src = fetchFromGitHub {
    owner = "pgvector";
    repo = "pgvector";
    tag = "v${finalAttrs.version}";
    hash = "sha256-JsZV+I4eRMypXTjGmjCtMBXDVpqTIPHQa28ogXncE/Q=";
  };

  meta = {
    description = "Open-source vector similarity search for PostgreSQL";
    homepage = "https://github.com/pgvector/pgvector";
    changelog = "https://github.com/pgvector/pgvector/raw/v${finalAttrs.version}/CHANGELOG.md";
    license = lib.licenses.postgresql;
    platforms = postgresql.meta.platforms;
    maintainers = [ ];
  };
})

Example workflow

# Build all package formats from one expression  
nix-build release.nix -A deb -A rpm -A nixpkg  

# Output:  
# ./result/deb/postgresql-custom_15.3.deb  
# ./result/rpm/postgresql-custom-15.3.rpm  
# ./result/nixpkg/*.nix  

Example release.nix

{ pkgs ? import <nixpkgs> {} }:  

let  
  pkg = import ./default.nix { inherit pkgs; };  
in {  
  deb = pkgs.runCommand "${pkg.name}-deb" {} ''  
    ${pkgs.nixpack}/bin/nixpack -f deb ${pkg} > $out  
  '';  

  rpm = pkgs.runCommand "${pkg.name}-rpm" {} ''  
    ${pkgs.nixpack}/bin/nixpack -f rpm ${pkg} > $out  
  '';  
}

[Vonng]

hi, thanks for the suggestion — Nix looks quite interesting; I’ve heard a bit about it before.

The current goal of the Pigsty extensions repository is to provide DEB/RPM artifacts that are fully compatible with the existing kernel and extension packages in the PGDG YUM/APT repositories, enabling PostgreSQL ecosystem components to run directly on mainstream Linux distributions.

In the longer term, Pigsty does intend to adopt a dedicated packaging specification to unify RPM/DEB packages across different platforms (maybe include macOS & nixos). Nix sounds quite promising. I’ll look further into whether Nix can serve these purposes and run some initial experiments.

[oneingan]

I'm trying to adapt your pigsty abstractions into NixOS systems using the NixOS module system and clan (as in https://clan.lol) framework.

When I get a MVP working i can share the details for people interested.