fix: raise default max_replication_slots from 5 to 10 in the postgres AMI - #2387
Closed
hunleyd wants to merge 2 commits into
Closed
Conversation
max_replication_slots is a single shared pool covering both logical and physical slots (confirmed against PostgreSQL's own docs). At 5, a project running Realtime plus a couple of read replicas plus any customer logical replication is already at or near the ceiling, with only 31 projects fleet-wide currently overriding this key. Matches PostgreSQL's own upstream default (10) and max_wal_senders, already 10 in this same file. Resolves INDATA-1301
The generated README feature bullet and its generator both hardcoded = 5, which the prior commit's default bump missed. Fixing README.md alone would revert on the next update_readme run, so both need the same edit.
Contributor
Author
|
Closing: review surfaced that supabase-admin-api's per-instance-size settings (pico/nano hardcode max_replication_slots=5, micro+ already at 10) override this template's default at boot via generated-optimizations.conf, which is included after this setting and wins under Postgres's last-assignment-wins parsing. This change has no observable effect at any instance size as written, so there's nothing to ship here. |
hunleyd
deleted the
hunleyd/fix/indata-1301-raise-default-max-replication-slots-from-5-to-10-in-the-postgres-ami
branch
August 21, 2026 18:23
PostgreSQL Extension Dependency Analysis: PR #2387
SummaryNo extensions had dependencies with MAJOR version updates. Full Analysis ResultsPostgreSQL 15 Extension DependenciesPostgreSQL 17 Extension DependenciesOrioleDB 17 Extension Dependencies |
PostgreSQL Package Dependency Analysis: PR #2387
SummaryNo packages had MAJOR version updates. Full Analysis ResultsPostgreSQL 15 Dependency ChangesExtracting PostgreSQL 15 dependencies...
Runtime Closure Size
Raw Dependency ClosurePostgreSQL 17 Dependency ChangesExtracting PostgreSQL 17 dependencies...
Runtime Closure Size
Raw Dependency Closure |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The AMI's postgresql.conf template caps
max_replication_slotsat 5, overriding PostgreSQL's own upstream default of 10. This is a single shared pool covering both logical and physical replication slots, so Realtime, customer logical replication, and physical read-replica slots all draw from the same ceiling. Raises the default to 10 to match upstream and give more headroom before that ceiling is hit.Details
ansible/files/postgresql_config/postgresql.conf.j2—max_replication_slots5 → 10, matchingmax_wal_senders(already 10 in this same file) and PostgreSQL's own upstream default.Surfaced while reviewing supabase/platform#35057 (physical replication slots for read replicas): every read replica now permanently consumes one of these slots on its primary. Only 31 projects fleet-wide currently override this key, meaning almost every project is capped at the AMI's default — a project running Realtime plus a couple of read replicas plus any customer logical replication is already at or near 5.
Only affects newly-provisioned instances going forward; existing instances keep their current setting until their next config regeneration/restart (
max_replication_slotsispostmaster-context).Testing
grep -rn max_replication_slots)Resolves INDATA-1301