mirror of
https://github.com/supabase/supabase.git
synced 2026-10-09 03:15:06 +03:00
Leandro Pereira
32764ec483
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Docs to expose current Realtime Broadcast Replay limits. -- Fixes REAL-874 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified how broadcast replay storage retention works, including the daily-partition behavior and that replays are dropped after 72 hours (messages are available for at least 72 hours and up to ~4 days depending on send time). * Updated the “Limits by plan” table with broadcast replay retention (72 hours) and broadcast replay messages per request (25) across all plans. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
67 lines
4.2 KiB
Plaintext
67 lines
4.2 KiB
Plaintext
---
|
|
id: 'limits'
|
|
title: 'Realtime Limits'
|
|
description: 'Understanding Realtime limits'
|
|
sidebar_label: 'Limits'
|
|
---
|
|
|
|
Our cluster supports millions of concurrent connections and message throughput for production workloads.
|
|
|
|
<Admonition type="note">
|
|
|
|
Upgrade your plan to increase your limits. Without a spend cap, or on an Enterprise plan, some limits are still in place to protect budgets. All limits are configurable per project. [Contact support](/dashboard/support/new) if you need your limits increased.
|
|
|
|
</Admonition>
|
|
|
|
## Limits by plan
|
|
|
|
| | Free | Pro | Pro (no spend cap) | Team | Enterprise |
|
|
| -------------------------------------------------------------------------------------------------- | -------- | -------- | ------------------ | -------- | ---------- |
|
|
| **Concurrent connections** | 200 | 500 | 10,000 | 10,000 | 10,000+ |
|
|
| **Messages per second** | 100 | 500 | 2,500 | 2,500 | 2,500+ |
|
|
| **Channel joins per second** | 100 | 500 | 2,500 | 2,500 | 2,500+ |
|
|
| **Channels per connection** | 100 | 100 | 100 | 100 | 100+ |
|
|
| **Presence keys per object** | 10 | 10 | 10 | 10 | 10+ |
|
|
| **Presence messages per second** | 20 | 50 | 1,000 | 1,000 | 1,000+ |
|
|
| **Presence calls per client, per 30 seconds** | 5 | 5 | 5 | 5 | 5 |
|
|
| **Broadcast payload size** | 256 KB | 3,000 KB | 3,000 KB | 3,000 KB | 3,000+ KB |
|
|
| **Postgres change payload size ([**read more**](#postgres-changes-payload-limit))** | 1,024 KB | 1,024 KB | 1,024 KB | 1,024 KB | 1,024+ KB |
|
|
| **Broadcast replay retention ([**read more**](/docs/guides/realtime/broadcast#broadcast-replay))** | 72 hours | 72 hours | 72 hours | 72 hours | 72 hours |
|
|
| **Broadcast replay messages per request** | 25 | 25 | 25 | 25 | 25 |
|
|
|
|
Beyond the Free and Pro Plan you can customize your limits by [contacting support](/dashboard/support/new).
|
|
|
|
## Limit errors
|
|
|
|
When you exceed a limit, errors will appear in the backend logs and client-side messages in the WebSocket connection.
|
|
|
|
- **Logs**: check the [Realtime logs](/dashboard/project/_/database/realtime-logs) inside your project Dashboard.
|
|
- **WebSocket errors**: Use your browser's developer tools to find the WebSocket initiation request and view individual messages.
|
|
|
|
<Admonition type="tip" title="Realtime Inspector">
|
|
|
|
You can use the [Realtime Inspector](https://realtime.supabase.com/inspector/new) to reproduce an error and share those connection details with Supabase support.
|
|
|
|
</Admonition>
|
|
Some limits can cause a Channel join to be refused. Realtime will reply with one of the following WebSocket messages:
|
|
|
|
### `too_many_channels`
|
|
|
|
Too many channels currently joined for a single connection.
|
|
|
|
### `too_many_connections`
|
|
|
|
Too many total concurrent connections for a project.
|
|
|
|
### `too_many_joins`
|
|
|
|
Too many Channel joins per second.
|
|
|
|
### `tenant_events`
|
|
|
|
Connections will be disconnected if your project is generating too many messages per second. `supabase-js` will reconnect automatically when the message throughput decreases below your plan limit. An `event` is a WebSocket message delivered to, or sent from a client.
|
|
|
|
## Postgres changes payload limit
|
|
|
|
When this limit is reached, the `new` and `old` record payloads only include the fields with a value size of less than or equal to 64 bytes.
|