mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 18:05:11 +03:00
Miranda Limonczenko
7ce4ee53ae
Closes [DOCS-1289](https://linear.app/supabase/issue/DOCS-1289/get-the-linter-to-fix-what-it-flags-or-retirereplace-the-linter) Stacked on #50600, which points contributors at the authoring skills. Merge that one first. ## Problem Contributors experienced friction with the linter. They felt nickle and dimed for tiny nits and felt detracted from the work itself. PRs would become noisy with tiny one-word suggestions. Additionally, our homegrown linter is not very intelligent, causing frequent overrides. ## Solution This removes the linter entirely in favor of directing contributors to use SKILLS instead. The removal entails... - **CI.** Delete the three `docs_lint` workflows: the PR check, the external-PR comment companion, and the nightly `--fix` bot. Drop the stale `zizmor.yml` ignore entry for the deleted workflow. - **Tooling.** Delete `supa-mdx-lint.config.toml` and the 14 rule files. Drop the `lint:mdx` script and the `@supabase/supa-mdx-lint` dependency from docs, learn, and ui-library, and regenerate the lockfile. - **Content.** Remove the 181 directives. A separate commit carries Prettier's reformatting of the tables and blank lines those comments had suppressed, so the deletion commit stays readable. No prose changes. - **Style guide.** The word list states each rule directly instead of describing what the linter flagged. Every term survives, including the phrase groups that mirrored `Rule004ExcludeWords`. - **Skills.** `write-the-docs`, `edit-the-docs`, and `review-the-docs` drop `pnpm lint:mdx` from their self-review commands and check the word list directly. `ask-the-docs`'s CI reference drops both workflows. ## Manual testing 1. Run `git grep -i supa-mdx-lint -- . ':!pnpm-lock.yaml'`. No matches. 2. Run `pnpm install --frozen-lockfile --lockfile-only`. It passes, so the lockfile matches the three trimmed manifests. 3. Run `git diff master...HEAD --name-only --diff-filter=ACMR | grep -E '\.(md|mdx)$' | xargs npx prettier --config prettier.config.mjs --check`. All changed markdown passes. 4. Open the [reformatted filter table](https://docs-git-docs-retire-mdx-linter-supabase.vercel.app/docs/guides/observability/logs#filter-events) on the preview and compare it with [production](https://supabase.com/docs/guides/observability/logs#filter-events). The table renders the same. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Documentation guidance now uses manual prose and terminology review with the shared word list. * Clarified storage configuration and common Realtime channel mistakes. * Improved table formatting, text wrapping, and selected reference links. * Updated documentation authoring and review guidance. * **Chores** * Retired automated MDX linting from workflows and local validation commands. * Removed lint-suppression markers throughout documentation without changing instructions. * Added targeted documentation review guidance for pull requests. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
109 lines
7.3 KiB
Plaintext
109 lines
7.3 KiB
Plaintext
---
|
|
title: 'Settings'
|
|
description: 'Realtime Settings that allow you to configure your Realtime usage.'
|
|
subtitle: 'Realtime Settings that allow you to configure your Realtime usage.'
|
|
---
|
|
|
|
## Settings
|
|
|
|
<Admonition type="caution">
|
|
|
|
All changes made in this screen will disconnect all your connected clients to ensure Realtime starts with the appropriate settings and all changes are stored in Supabase middleware.
|
|
|
|
</Admonition>
|
|
|
|
<Image
|
|
alt="Usage page navigation bar"
|
|
src={{
|
|
light: '/docs/img/guides/platform/realtime/realtime-settings--light.png',
|
|
dark: '/docs/img/guides/platform/realtime/realtime-settings--dark.png',
|
|
}}
|
|
|
|
width={4600}
|
|
height={2600}
|
|
/>
|
|
|
|
You can set the following settings using the Realtime Settings screen in your Dashboard. For the ceilings your plan allows, see [Realtime Limits](/docs/guides/realtime/limits); the rate and payload limits are only editable while your organization's spend cap is disabled. For the errors below, see [Operational Error Codes](/docs/guides/realtime/error_codes).
|
|
|
|
### Enable Realtime service
|
|
|
|
**Type:** Toggle · **Options:** Enabled, Disabled · **Default:** Enabled
|
|
|
|
Determines if the Realtime service is enabled or disabled for your project.
|
|
|
|
- **Enabled**: normal operation.
|
|
- **Disabled**: connected clients are disconnected, new connections are rejected with `403` and `Realtime was disabled for this tenant`, joins receive `RealtimeDisabledForTenant`, and Broadcast REST requests are rejected with `403`. Realtime also releases the database connections and Postgres Changes replication slot it holds for your project, and reopens them on the first connection after you enable it again.
|
|
|
|
### Allow public access to channels
|
|
|
|
**Type:** Toggle · **Options:** Enabled, Disabled · **Default:** Enabled
|
|
|
|
Determines whether Realtime allows public channels, or restricts your project to private channels with [Realtime Authorization](/docs/guides/realtime/authorization).
|
|
|
|
- **Enabled**: no policy check runs, but anyone holding your project's anon key can subscribe to and broadcast on any public channel.
|
|
- **Disabled**: every join is checked against the Row Level Security policies on `realtime.messages`, so each join costs one authorization query. Clients that don't set `config.private` to `true` are rejected with `PrivateOnly`. With no policies, clients connect but receive no messages.
|
|
|
|
### Database connection pool size
|
|
|
|
**Type:** Number of connections · **Range:** 1 to your database's `max_connections` · **Default:** varies by compute size
|
|
|
|
Determines the number of connections used for Realtime Authorization RLS checking. Results are cached per client, so the pool is used on each private channel join, each `access_token` refresh, and each private Broadcast REST request.
|
|
|
|
- **Too low**: checks queue and time out. Clients receive `IncreaseConnectionPool`, broadcasts are dropped, and presence calls fail. Once timeouts in a 30-second window reach the pool size, later checks fail immediately without reaching the database.
|
|
- **Too high**: the pool competes with your application for your database's `max_connections`. If Realtime's total requirement doesn't fit, it refuses to start with `DatabaseLackOfConnections`.
|
|
|
|
See [Database connections](/docs/guides/realtime/concepts#database-connections) for the defaults per compute size.
|
|
|
|
### Postgres Changes connection pool size
|
|
|
|
**Type:** Number of connections · **Range:** 1 to 20 · **Default:** 2
|
|
|
|
Determines the number of connections used to create [Postgres Changes](/docs/guides/realtime/postgres-changes) subscriptions when clients subscribe. It's only used while subscriptions are created; streaming the changes uses a separate connection.
|
|
|
|
- **Too low**: subscription creation times out during bursts. Clients receive a `postgres_changes` system error with `Too many database timeouts` and retry after 5 to 10 seconds.
|
|
- **Too high**: it counts toward the same connection budget as every other Realtime pool.
|
|
|
|
Raise this value if many clients subscribe at the same time, such as after a deploy or a mass reconnect.
|
|
|
|
### Max concurrent clients
|
|
|
|
**Type:** Number of clients · **Range:** 1 to your plan's [concurrent connections](/docs/guides/realtime/limits#limits-by-plan) limit · **Default:** your plan's limit
|
|
|
|
Determines the maximum number of clients that can be connected. A client is one WebSocket connection, no matter how many channels it joins.
|
|
|
|
- **Too low**: new connections are rejected with `429` and `Too many connected users`. Existing clients are unaffected.
|
|
- **Too high**: each connection consumes memory on the Realtime nodes, so this setting acts as a capacity and cost control.
|
|
|
|
### Max events per second
|
|
|
|
**Type:** Number of events per second · **Range:** 1 to your plan's [messages per second](/docs/guides/realtime/limits#limits-by-plan) limit · **Default:** your plan's limit
|
|
|
|
Determines the maximum number of events per second that can be sent, measured as a rolling average over the previous minute. An event is a message sent by a client or delivered to one, so one broadcast to 100 subscribers counts as 100 events.
|
|
|
|
- **Too low**: channels that exceed the average are closed with `Too many messages per second`, which `supabase-js` recovers from by rejoining. Broadcast REST requests are rejected with `429`; those responses carry `x-rate-limit` and `x-rate-limit-remaining` headers you can use to slow down first.
|
|
- **Too high**: Realtime stops throttling broadcast fan-out, which removes the protection against a runaway loop or a mass reconnect, and raises the ceiling on your Realtime spend.
|
|
|
|
### Max presence events per second
|
|
|
|
**Type:** Number of events per second · **Range:** 1 to your plan's [presence messages per second](/docs/guides/realtime/limits#limits-by-plan) limit · **Default:** your plan's limit
|
|
|
|
Determines the maximum number of presence events per second that can be sent, using the same rolling average as [Max events per second](#max-events-per-second) but checked before the event is sent rather than after delivery.
|
|
|
|
- **Too low**: presence tracking and syncing fail and the channel is closed with `Too many presence messages per second`.
|
|
- **Too high**: rapid `track` and `untrack` cycles can generate presence storms, because each change is broadcast to every client on the channel and also counts toward [Max events per second](#max-events-per-second).
|
|
|
|
<Admonition type="note">
|
|
|
|
A separate per-client limit also applies to presence, independent of this project-wide setting. A client that exceeds it is closed with `Client presence rate limit exceeded`. See [Realtime Limits](/docs/guides/realtime/limits) for the value on your plan.
|
|
|
|
</Admonition>
|
|
|
|
### Max payload size in KB
|
|
|
|
**Type:** Size in KB · **Range:** 1 to your plan's [broadcast payload size](/docs/guides/realtime/limits#limits-by-plan) limit · **Default:** your plan's limit
|
|
|
|
Determines the maximum payload size in KB that can be sent.
|
|
|
|
- **Too low**: oversized broadcasts are dropped, and the sender only learns about it if it set `ack_broadcast` to `true`. Broadcast REST requests are rejected with `422`, and an oversized presence `track` closes the channel with `Track message size exceeded`.
|
|
- **Too high**: large messages increase memory and bandwidth usage on every subscriber, since each message is delivered to all clients on the channel. Postgres Changes payloads have a [separate limit](/docs/guides/realtime/limits#postgres-changes-payload-limit).
|