Project
neondatabase/neon — serverless PostgreSQL with storage/compute separation (pageserver, safekeeper, proxy, storage_controller + a forked PostgreSQL for compute).
Why this is a request, not a PR
Investigation suggests packaging Neon as a single pantry project is not a clean fit. Filing this for discussion before any recipe is pushed.
What Neon's build chain looks like
The top-level make builds three things together:
- Vendored, patched PostgreSQL — Neon's
Makefile builds v14, v15, v16 and v17 of a forked Postgres from vendor/postgres-vXX submodules into ./pg_install/. Each version is a full PG configure/build (icu, libxml, libxslt, lz4, zstd, openssl, readline, uuid; libseccomp + util-linux on Linux).
- Rust workspace — ~10+ binaries via
cargo install: pageserver, safekeeper, storage_broker, storage_controller, storage_scrubber, storcon_cli, compute_ctl, endpoint_storage, neon_local, pagectl, pagebench, wal_craft. Deps include protobuf, openssl, icu, libpq.
- Neon Postgres extensions linked against the forked PG above.
Why a pantry recipe is awkward
- CI budget: a clean build = 4× full PostgreSQL + a large Rust workspace. Likely well outside pantry's per-recipe budget.
- Versioning: upstream tags three release streams independently —
release-NNNN (storage), release-compute-NNNN (forked PG), release-proxy-NNNN (proxy). Pantry's single versions: stream doesn't model this cleanly.
- Naming conflict:
notroj.github.io/neon (WebDAV client) already occupies neon in pantry — user-facing aliasing would be confusing.
- Deployment model: upstream explicitly states self-hosted Neon is not production-ready; it's deployed as a service / Docker stack. There is no single end-user CLI —
neon_local is a dev/test orchestrator.
- Closest prior art: the community bayandin/homebrew-tap splits this across three formulae (
neon-postgres, neon-storage, neon-extension) plus a neon-local meta. Pantry doesn't have a clean sub-package idiom matching that shape.
Precedent
Similar large multi-component DB systems already on hold in pantry:
Options
- Don't package (recommend). Users wanting local Neon should use Docker /
neondatabase/neon_local per upstream guidance.
- Storage-only recipe that depends on a pre-built or separate
neondatabase.com/postgres pantry project containing the forked PG (4 PG versions). Doubles the CI footprint and still ships dev-only binaries.
- Mirror the bayandin layout with three pantry projects under
neondatabase.com/{neon,postgres,extensions}. Heavy, and the use-case for end users is unclear.
Happy to push a recipe along any of these paths if a maintainer signals which (if any) is in scope. Otherwise my recommendation is to close as wontfix and document the rationale.
Project
neondatabase/neon — serverless PostgreSQL with storage/compute separation (pageserver, safekeeper, proxy, storage_controller + a forked PostgreSQL for compute).
Why this is a request, not a PR
Investigation suggests packaging Neon as a single pantry project is not a clean fit. Filing this for discussion before any recipe is pushed.
What Neon's build chain looks like
The top-level
makebuilds three things together:Makefilebuilds v14, v15, v16 and v17 of a forked Postgres fromvendor/postgres-vXXsubmodules into./pg_install/. Each version is a full PG configure/build (icu, libxml, libxslt, lz4, zstd, openssl, readline, uuid; libseccomp + util-linux on Linux).cargo install:pageserver,safekeeper,storage_broker,storage_controller,storage_scrubber,storcon_cli,compute_ctl,endpoint_storage,neon_local,pagectl,pagebench,wal_craft. Deps include protobuf, openssl, icu, libpq.Why a pantry recipe is awkward
release-NNNN(storage),release-compute-NNNN(forked PG),release-proxy-NNNN(proxy). Pantry's singleversions:stream doesn't model this cleanly.notroj.github.io/neon(WebDAV client) already occupiesneonin pantry — user-facing aliasing would be confusing.neon_localis a dev/test orchestrator.neon-postgres,neon-storage,neon-extension) plus aneon-localmeta. Pantry doesn't have a clean sub-package idiom matching that shape.Precedent
Similar large multi-component DB systems already on hold in pantry:
Options
neondatabase/neon_localper upstream guidance.neondatabase.com/postgrespantry project containing the forked PG (4 PG versions). Doubles the CI footprint and still ships dev-only binaries.neondatabase.com/{neon,postgres,extensions}. Heavy, and the use-case for end users is unclear.Happy to push a recipe along any of these paths if a maintainer signals which (if any) is in scope. Otherwise my recommendation is to close as wontfix and document the rationale.