From b323e583f8006ff5aedb0e42723ec42e757e67ca Mon Sep 17 00:00:00 2001 From: Bruno Andrade <1145012+bmpandrade@users.noreply.github.com> Date: Fri, 13 Oct 2023 18:21:39 +0100 Subject: [PATCH] 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 Co-authored-by: Greg Richardson * docs: quick change on compute-add-ons for repl slots --------- Co-authored-by: Div Arora Co-authored-by: Greg Richardson --- .../pages/guides/platform/compute-add-ons.mdx | 25 +++++++++++++++++++ .../realtime/bring-your-own-database.mdx | 2 ++ 2 files changed, 27 insertions(+) diff --git a/apps/docs/pages/guides/platform/compute-add-ons.mdx b/apps/docs/pages/guides/platform/compute-add-ons.mdx index e809e93476a..646cb64adac 100644 --- a/apps/docs/pages/guides/platform/compute-add-ons.mdx +++ b/apps/docs/pages/guides/platform/compute-add-ons.mdx @@ -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 | + + + +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. + + + export const Page = ({ children }) => export default Page diff --git a/apps/docs/pages/guides/realtime/bring-your-own-database.mdx b/apps/docs/pages/guides/realtime/bring-your-own-database.mdx index db805ba7b22..5e87c26daf4 100644 --- a/apps/docs/pages/guides/realtime/bring-your-own-database.mdx +++ b/apps/docs/pages/guides/realtime/bring-your-own-database.mdx @@ -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