docs: update compute addons with pg repl slots and wal senders (#18150)

* docs: update compute addons with pg repl slots and wal senders

* docs: update compute-addons and replication slots

Co-authored-by: Div Arora <darora@users.noreply.github.com>
Co-authored-by: Greg Richardson <greg.nmr@gmail.com>

* docs: quick change on compute-add-ons for repl slots

---------

Co-authored-by: Div Arora <darora@users.noreply.github.com>
Co-authored-by: Greg Richardson <greg.nmr@gmail.com>
This commit is contained in:
authored and GitHub committed 2023-10-13 18:21:39 +01:00
1 parent e32051040a
commit b323e583f8
2 files changed
+27

No files matched your search

@@ -62,6 +62,31 @@ If you need consistent disk performance, choose the 4XL or larger compute add-on
If you're unsure of how much throughput or IOPS your application requires, you can load test your project and inspect these [metrics in the Dashboard](https://supabase.com/dashboard/project/_/reports). If the `Disk IO % consumed` stat is more than 1%, it indicates that your workload has burst beyond the baseline IO throughput during the day. If this metric goes to 100%, the workload has used up all available disk budget and will revert to baseline performance. Projects that use any disk budget are good candidates for upgrading to a larger compute add-on with higher baseline throughput.
## Postgres Replication Slots and WAL Senders
[Replication Slots](https://postgresqlco.nf/doc/en/param/max_replication_slots) and [WAL Senders](https://postgresqlco.nf/doc/en/param/max_wal_senders/) are used to enable [Postgres Replication](/docs/guides/database/replication).
The maximum number of replication slots and WAL senders depends on your compute add-on plan, as follows:
| Plan | Max Replication Slots | Max WAL Senders |
| ------- | --------------------- | --------------- |
| Starter | 5 | 5 |
| Small | 5 | 5 |
| Medium | 5 | 5 |
| Large | 8 | 8 |
| XL | 24 | 24 |
| 2XL | 80 | 80 |
| 4XL | 80 | 80 |
| 8XL | 80 | 80 |
| 12XL | 80 | 80 |
| 16XL | 80 | 80 |
<Admonition type="caution">
As mentioned in the Postgres [documentation](https://postgresqlco.nf/doc/en/param/max_replication_slots/), setting `max_replication_slots` to a lower value than the current number of replication slots will prevent the server from starting. If you are downgrading your compute add-on, please ensure that you are using fewer slots than the maximum number of replication slots available for the new compute add-on.
</Admonition>
export const Page = ({ children }) => <Layout meta={meta} children={children} />
export default Page
@@ -31,6 +31,8 @@ Realtime relies on Postgres' logical replication functionality to get database c
- `max_replication_slots`: we recommend `10` because Realtime requires a few slots plus the slots you'll need for your non-Realtime logical replication needs.
- `max_slot_wal_keep_size`: we recommend `1024` (MB) so Realtime can attempt to deliver more database changes stored in Postgres.
See [Compute Add-ons](/docs/guides/platform/compute-add-ons#postgres-replication-slots-and-wal-senders) for the recommended `max_replication_slots` at different instance sizes based on the values we use for our own cloud offering.
## Realtime Database Setup
### `supabase_realtime` Publication