I see that starter plan has a concurrency limit of 16 queries and 256 for pro plan.
If a query is passively listening for changes, are they count towards one query in concurrency?
So if there are 16 users opening my app and do nothing, does that mean the limit is reached and new users will not be able to execute queries?
#How does query concurrency limit work?
white mountain
dim rampartBOT
Hi @white mountain. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
Based on the knowledge sources, I can explain how query concurrency limits work in Convex.
Yes, Convex has different concurrency limits based on your plan. As you noted, the Starter plan allows 16 concurrent queries, while the Professional plan allows 256 concurrent queries. These limits represent the number of query functions you can run simultaneously.
When a client subscribes to a query using Convex's real-time features, it does count toward your concurrent query limit. However, there's an important optimization to be aware of: Convex deduplicates subscriptions to the same query. As explained in a Discord support thread:
"By default the convex client deduplicates all subscriptions to the same query into a single subscription. So you don't have to worry about 5 uses of the same
useQueryinvoking 5 different server-side function calls. It will be just one." Discord support thread
This means that if multiple users are subscribing to the exact same query (with the same parameters), they'll share a single subscription on the server side, which only counts as one toward your concurrency limit.
So in your scenario where 16 users open your app and do nothing, whether you hit the limit depends on:
- How many unique queries each user is subscribing to
- Whether users are sharing the same queries
If each user subscribes to a completely different query, then yes, with 16 users on the Starter plan, you would reach the limit. But if users are subscribing to the same queries, the deduplication feature would help you stay under the limit.
If you do hit the limit, new query subscriptions would fail until some existing ones are released. This could potentially prevent new users from executing queries.
For applications expecting significant growth, the Professional plan's higher concurrency limits (256 for queries) would provide more headroom.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
white mountain
@dim rampart Let's say there will be a single type of query to subscribe to price changes of 10 items on the page.
Each item will need to invoke a query to listen to price changes.
dim rampartBOT
Let me check the knowledge base for you again. One moment! :books:
Based on your scenario, I'll explain how Convex would handle multiple queries for price changes.
If you have a page displaying 10 items and each item needs to subscribe to price changes, there are a couple of approaches to consider:
-
Individual queries per item: If you create a separate query subscription for each item's price, you would have 10 concurrent queries per user. With the Starter plan's limit of 16 concurrent queries, you could only support 1 user with some queries to spare before hitting the limit.
-
Batched query approach: A more efficient approach would be to create a single query that returns price data for all 10 items at once. This way, each user would only consume one concurrent query slot regardless of how many items are on the page.
As mentioned in the Convex documentation:
"Convex automatically caches the result of your query functions so that future calls just read from the cache. The cache is updated if the data ever changes." Realtime documentation
Additionally, Convex's client deduplication feature means that if multiple users are viewing the same items and subscribing to the same queries (with identical parameters), these would be deduplicated on the server side:
"By default the convex client deduplicates all subscriptions to the same query into a single subscription." Discord support thread
This means if 100 users are all viewing the same 10 items with the batched query approach, you'd still only be using a single concurrent query slot on the server.