PubNub API Limits
General API Limits
All API requests, made either by the SDK or directly through the REST interface, can be throttled if Requests Per Second (RPS) exceed 25. This limit is applicable for every PubNub API. Please contact PubNub Support if you have a need for greater than 25 requests per second.
Publish
| Function | Soft Limit (Best Practices) | Hard Limit | If hard limited is exceeded? |
|---|---|---|---|
| Publish Rate | 10-15 messages/sec per channel NOTE: it's a best practice to limit the publish rate not because PubNub can't keep up - you should be able to publish as fast as your network/hardware will allow and PubNub will absorb it - but because the subscriber may miss out on messages if the subscribe rate is too slow. A slow subscribe rate causes messages to overflow the server side channel message queue before the subscriber can receive them. The queue only overflows if during the reconnect time, you have published over 100 messages. Average reconnect time is around 150ms, technically that means publishing ~600/second. Keep in mind the queue could also overflow during a brief internet disconnection. However, if you have a multiplex connection, the total messages received can't exceed 100 over all the channels combined. If it takes 230ms to reconnect, you can only actually get ~400 per second (4 reconnects per second, each 230ms between, 100 messages per connect). That means if you publish 500 messages per second, the subscriber will miss some of them. Also consider this isn't taking into consideration the download time for 100 messages (potentially 32Kb * 100). Typically reconnection is faster than that. If you're on AWS, your reconnect might be as low as 30-50ms. With a 50ms reconnect time, you can publish close to 2000 messages per second, and the subscriber won't miss messages due to overflow. The most complicated part is multiplexed subscriber connections, it's 100 messages total across all the channels, so you can't publish more than 100 messages in the reconnect time across channels in the multiplex channel list. Hard to give an exact recommendation here! Also applies to channel group and wildcard subscriptions in addition to multiplexing. Increasing the queue size for the sub-key (to 300 or 500, for example) will allow the subscribers to keep up with more messages. Also, the queue life (TTL) must be considered in addition to the queue size; refer to the Message Buffer Cache section of this doc. | No throttling on keys in good standing (either any key with a paid plan present or keys on Free Tier at usage levels within the allowed limits). Use HTTP Pipelining for higher throughput. | Free Tier keys exceeding usage quotas are subject to deactivation without warning, though for a first overage we will attempt to get in contact before disabling keys. All other keys, N/A Error message (Channel quota exceeded) |
| # of Publishers per channel or keyset | Unlimited | N/A | |
| Message Size | Less than < 30 KiB to be safe. | Length of GET request, including HTTP headers & URI encoding overhead (~32 KiB) | HTTP 400 error |
| Channel Name Length | 64 characters | 92 Characters (97 characters including padding for base64 encoding) | |
| # of API keys per PubNub account? | An API is available if you need to manage an large number of keys (> 50). Contact us at support@pubnub.com if you need access to the Key Provisioning API. | Unlimited | N/A |
Subscribe
| Function | Soft Limit | Hard Limit | If hard limited is exceeded? |
|---|---|---|---|
| Subscribe Rate | Most of the considerations mentioned above in soft limits for publish rate are actually because of the limitations on the subscriber end (queue limit, round trips, etc). | No limit Use HTTP Streaming for maximum throughput N/A | |
| # of Channels | Unlimited | N/A | |
| # of Subscribers per channel or keyset | Unlimited | N/A | |
| Message Buffer Cache | Size: 100 message queue TTL: 16 minutes maximum before cleared off the cache, but can be shorter (no guarantees). If longer than 8 to 10 minutes disconnect, use Storage & Playback NOTE: Each socket connection has an in-memory message queue (FIFO) that holds onto recently published messages for the cache duration (12 to 16 minutes) and is limited to the most recent 100 messages. Consequently, publishing over 100 messages in the window of the subscribe reconnect time inevitably results in older messages overflowing the queue and getting discarded. For long term, reliable persistence and retrieval of missed message, you should enable Storage & Playback add-on with a duration up to 30 days or even unlimited and use the history API to retrieve those messages. | Size: Configurable on our end, may be added costs TTL: Currently defined with a hard limit of 20 mins and a configurable effective percentage that controls the behavior of the network. So, a percentage of 90 would mean the effective TTL is 18 mins. Currently it's set to 80% or 16 mins | |
| Catch-Up | 100 messages (or size of buffer cache) | N/A | |
| Channel Name Length | 64 characters | 92 Characters (97 characters including padding for base64 encoding) | |
| # of Sockets/Instances per client | PubNub does not limit the number of sockets/instances you can create, but TCP connections are typically limited by the device/platform (for instance, some browsers only allow up to 40 TCP connections). Keep in mind each PubNub client instance creates 2 TCP socket connections: one for subscribes and the other for non-subscribe operations. | Unlimited | N/A |
| Multiplexing (available without Stream Controller) | 10 to 50 channels When subscribing to many channels, channel groups allows for the persistence of channel lists. | No limit in client SDKs, but we advertise a hard limit of 100 channels. No server side limit, only limited by URI length. | |
| Channel Groups | Up to 10 channel groups, each with 2,000 channels for a total of 20,000 channels. 200 channels can be added at a time. | If subscribing to more than 10 channel groups, receive 400 HTTP status code with description Maximum channel registry count exceeded | |
| Wildcard Subscribe | Depends on subscribe rate NOTE: refer to the note for Publish Rate | 3 levels (2 dots) of wildcards: a. a.b. No limit to # of channels able to subscribe to in a wildcard subscribe. Wildcard Channel Names aren't allowed in Channel Groups. | |
| Channel Group Name Length | 92 Characters (97 characters including padding for base64 encoding) |
Files
| Function | Soft Limit | If hard limited is exceeded? |
|---|---|---|
| File Size | 5 MB | Contact us at support@pubnub.com to increase the file size limit. |
| File Retention | 1, 3, 7, 15, or 30 days, or Forever |
Presence
| Function | Soft Limit | Hard Limit |
|---|---|---|
| Heartbeat | Minimum: 1 minute heartbeat & 29 second interval | Minimum: heartbeat:10; interval: 4 (lowest common denominator across 3.x SDKs; each have different hard limits) 4.x SDKs do not currently have limitations. |
| Presence Announce Max | 100 | We can adjust this limit, but there are considerations |
| Webhook Retries | Presence webhooks will try to POST to your URL endpoint for a maximum of 4 times, each with a 5s timeout; Ensure that the customer's server (REST endpoint) returns 200 NOTE: If a channel has reached the Presence Announce Max limit, we will not send webhook requests for that channel | If webhook has reached maximum number of retries, the request is lost. |
| Global Here Now | In case of a sizeable user base (100k+), chunk out to smaller global presence channels and do individual here_now calls on those (no more than 10k per global presence channel) | No limit - latency can get really high because of no pagination |
Storage
| Function | Soft Limit | Hard Limit |
|---|---|---|
| Data Retention | 1, 3, 7, 15, or 30 days, or Forever | N/A |
Objects
| Item | Limit | Notes |
|---|---|---|
| Size of a record | 32 KiB | Maximum size of a user or channel metadata stored in the database, including custom fields. |
| Max user metadata records | 1 million | Recommended maximum number of user metadata records using Objects API. |
| Max channel metadata records | 1 million | Recommended maximum number of channel metadata records using Objects API. |
| Members added in a channel | 5,000 | Recommended maximum number of members per channel using Objects API. |
| Memberships per user | 50,000 | Recommended maximum number of memberships per user using Objects API. |
| Members per transaction request | 20 | Maximum number of members added or removed in a single call using Objects API. |
Mobile Push
| Function | Soft Limit |
|---|---|
| # of Push Certificates | 1 APNs certificate & 1 FCM key per PubNub Key Set |
| Push Notification Message Size | Maximum: 2 kB for APNs, 4 kB for FCM |
Access Manager
| Function | Soft Limit | Hard Limit |
|---|---|---|
| # of Tokens | No limits | N/A |
| Grant latency | Server to server (grant by server for server usage), give it 1 second between grant and usage Separate process (server grant, client usage), wait for grant callback before returning to client | N/A |
| Channels per grant | 200 | N/A |
| Auth-keys per grant | 200 | N/A |
| Granting on Wildcard Levels | Can only grant one level deep:a.* - you can grant on thisa.b.* - grant will not work on this. | If you grant on a.b.*, the grant will treat the pattern as a single channel with name a.b.* |