request: neondatabase/neon (serverless Postgres) — packaging feasibility

Aperta
  • Qualcosa non va?
#13,131 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
docker, postgresql, rust
Ambito
build-system, databases, devops

Direzione di ricerca

Start with Neon's top-level Makefile, the vendor/postgres-vXX submodules, and the Rust workspace build described in the issue. Review the linked cockroachdb precedent and the bayandin/homebrew-tap formula layout, then compare them with pantry's recipe model. Done means a maintainer-approved packaging direction or a documented decision not to package Neon; the issue does not currently identify a concrete implementation target.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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:

  1. 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).
  2. 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.
  3. 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

  1. Don't package (recommend). Users wanting local Neon should use Docker / neondatabase/neon_local per upstream guidance.
  2. 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.
  3. 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.

Lingua principale
C
Stelle
199
Fork
142
Merge medio
2h 33m
PR unite (30g)
145

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pkgxdev/pantry

Tutte le issue di pkgxdev/pantry

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.