Skip to content

[slopfix] docs(self-hosting): promote postgres from experimental to recommended OSS multi-node backend - #5341

Open
MasterPtato wants to merge 1 commit into
stack/slopfix-fix-self-host-repair-dev-compose-generation-kitchen-sink-serverful-runner-and-postgres-udb-bootstrap-wpvkrymufrom
stack/slopfix-docs-self-hosting-promote-postgres-from-experimental-to-recommended-oss-multi-node-backend-zsmysquk
Open

[slopfix] docs(self-hosting): promote postgres from experimental to recommended OSS multi-node backend#5341
MasterPtato wants to merge 1 commit into
stack/slopfix-fix-self-host-repair-dev-compose-generation-kitchen-sink-serverful-runner-and-postgres-udb-bootstrap-wpvkrymufrom
stack/slopfix-docs-self-hosting-promote-postgres-from-experimental-to-recommended-oss-multi-node-backend-zsmysquk

Conversation

@MasterPtato

@MasterPtato MasterPtato commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@MasterPtato

MasterPtato commented Jun 26, 2026

Copy link
Copy Markdown
Contributor Author

Stack for rivet-dev/rivet

Get stack: forklift get 5341
Push local edits: forklift submit
Merge when ready: forklift merge 5341

change zsmysquk

@claude

claude Bot commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

Review

Docs-only PR promoting PostgreSQL from experimental to recommended for multi-node self-hosting. Overall the new postgres.mdx sections (connection limits, resources, HA/backups, troubleshooting) are clear and well-organized. A few issues worth addressing before merge.

1. New NATS guidance contradicts the file most closely related to it (and one this PR itself edits)

vpc-air-gapped.mdx now says:

The built-in PostgreSQL pub/sub is sufficient for most deployments; very high-throughput deployments can add NATS as a dedicated pub/sub layer.

I checked this against the engine code and it's accurate: engine/packages/config/src/config/mod.rs auto-defaults pubsub to PostgresNotify (LISTEN/NOTIFY-backed, in engine/packages/universalpubsub/src/driver/postgres/) whenever database is Postgres and no pubsub is explicitly set. NATS is not required.

However, postgres.mdx, edited extensively elsewhere in this same PR, still says the opposite in sections this PR left untouched:

  • "Multi-node: Use PostgreSQL as the database and NATS for pub/sub." (Choosing a Backend)
  • "Multi-node PostgreSQL deployments require NATS as the pub/sub backend so engine nodes can coordinate." (Pub/Sub (NATS) section)

And production-checklist.mdx (also untouched by this PR) has a ## NATS section stating "Use NATS for pub/sub in multi-node deployments... NATS is the pub/sub backend that coordinates realtime messaging between engine nodes," with no mention that it's optional.

Since this PR is already reworking the multi-node PostgreSQL story and touches postgres.mdx directly, it would be worth fixing the "NATS required" language there and in production-checklist.mdx in the same change, rather than leaving contradictory claims live across the docs (one page says NATS is required for multi-node, the new page says it's only needed at high throughput).

2. /docs/self-hosting/multi-region is a stub

The new "Multi-Region" bullet in the Overview and the new ### Multi-Region section both link to /docs/self-hosting/multi-region with "see the full topology," but that page currently only contains <Info>Documentation coming soon</Info>. Minor, but the link promises content that doesn't exist yet. Consider softening the phrasing or filing a follow-up to fill in that page.

3. max_connections x 150 figure isn't derived from a code constant

I checked the actual pool sizing: each engine node opens two separate deadpool-postgres pools hardcoded to max_size: 64 (UDB in universaldb/src/driver/postgres/database.rs and the Postgres-notify pubsub driver in universalpubsub/src/driver/postgres/mod.rs), plus two dedicated non-pooled LISTEN connections, roughly 130 per node today, and neither pool size is currently configurable. The qualitative claim ("well over a hundred per node") holds, and 150 is a reasonable safety margin, but it reads as if it were a derived constant. Worth a footnote that it's a rule-of-thumb headroom figure rather than a fixed value, since a future change to the hardcoded 64 would silently invalidate the doc's math.

Minor nits

  • Double blank line before ## Troubleshooting in postgres.mdx (trailing artifact from the diff).

Nothing here blocks the core content improvements. Item 1 is the one I'd actually want resolved before merge, since it currently leaves the self-hosting docs giving readers opposite answers to "do I need NATS?" depending on which page they land on.

@NathanFlurry NathanFlurry changed the title [slopfix] docs(self-hosting): promote postgres from experimental to recommended OSS multi-node backend docs(self-hosting): promote postgres from experimental to recommended OSS multi-node backend Jun 26, 2026
@MasterPtato MasterPtato changed the title docs(self-hosting): promote postgres from experimental to recommended OSS multi-node backend [slopfix] docs(self-hosting): promote postgres from experimental to recommended OSS multi-node backend Jun 29, 2026
@MasterPtato
MasterPtato changed the base branch from stack/slopfix-fix-self-host-repair-dev-compose-generation-kitchen-sink-serverful-runner-and-postgres-udb-bootstrap-wpvkrymu to main August 7, 2026 00:39
@MasterPtato
MasterPtato force-pushed the stack/slopfix-docs-self-hosting-promote-postgres-from-experimental-to-recommended-oss-multi-node-backend-zsmysquk branch from 693655e to 5dfeb48 Compare August 7, 2026 01:27
@MasterPtato
MasterPtato changed the base branch from main to stack/slopfix-fix-self-host-repair-dev-compose-generation-kitchen-sink-serverful-runner-and-postgres-udb-bootstrap-wpvkrymu August 7, 2026 01:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant