Feature Request: nix packages support

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

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  
  '';  
}

Review the repository's existing packaging workflow, then compare it with the proposed default.nix and release.nix structure in the issue. Determine how a Nix branch and package definitions would fit alongside the current release artifacts. Done means reproducible Nix builds are integrated without breaking existing Debian and RPM packaging.