Can one analytics agent serve a thousand users? The limits aren't published
The queries-per-minute and concurrency limits for a single agent are undocumented. An engine with a known concurrency profile answers the question before the rollout.
THE PROBLEM
The queries-per-minute and concurrency limits for a single analytics agent are not documented, so teams planning a rollout to a thousand or more users cannot tell whether one agent will hold.
THE PROBLEM ANATOMY
Who it hits
Owns the agent rollout, and needs a concurrency number to plan it.
Owns the warehouse the agent runs on and the SLA behind it.
Owns the promise of agent analytics to the whole user base.
The situation
A team is ready to put an agent in front of a large user base and needs to know how many concurrent users one agent can support. The public answer is thin. The questions-per-minute limits, the concurrency ceiling, and the throughput are not documented, and threads on the topic collect follow-along replies rather than numbers. And the surface keeps widening. The same agent is now reachable from inside Excel and Google Sheets, so the user base is no longer the analysts who opted in, it is everyone who already has a spreadsheet open.
Without those limits, capacity planning becomes a guess. The rollout either over-provisions to be safe or ships and hopes the agent holds at peak.
The specific challenges
- No published limits: queries-per-minute and concurrency ceilings are undocumented
- Planning by guess: capacity for a thousand users cannot be sized from the data available
- Peak risk: the agent may hold in a pilot and fail at full traffic
- One shared path: many users route through a single agent with unknown throughput
WHAT IT COSTS
PRACTICAL
- Blind sizing: capacity is set without a concurrency number to plan against
- Load-test scramble: teams build their own tests to find the ceiling
BUSINESS
- Delayed rollout: the launch waits on limits no one can confirm
- Reputation risk: an agent that stalls at peak lands in front of the whole user base
EMOTIONAL
- Launch anxiety: the owner ships without knowing the ceiling
- Unanswered questions: the same concurrency question gets asked and never resolved
THE WAY OUT
An agent path with a published concurrency profile
The ceiling on an Agent rollout sits in a layer you can't inspect or resize. The alternative is to run the agent path on compute with documented, load-tested limits, so sizing for a thousand users is arithmetic instead of a support ticket.
Size the fan-out: one user question turns into several machine-generated queries: schema checks, candidate SQL, retries after errors. e6data's engine sustains 1,000+ QPS at p95 under two seconds, so you can plan for that amplification before launch rather than discovering it at peak.
Scale in single-vCPU steps: compute follows concurrent load up and down. A pilot that holds at 50 users holds the same way at 1,000 because the profile grows without changing shape.
Keep the tables: your table formats, catalog, and access controls stay where they are. The agent's queries move onto compute you can size, observe, and load-test yourself before launch.
The result is a concurrency number the rollout can be planned on, instead of a limit no one can confirm. Setup and connection details are in the query engine documentation.
See how the Query engine scales to users Share your problem, talk with a founding team member →Book a demo on your own workloads
Reach out to book a demo, share challenges you're facing, and tell us how this fits into what you're currently working on or thinking about.
Prefer to self-serve? Problems we're solving →