---
title: TOO_MANY_SIMULTANEOUS_QUERIES ClickHouse® error
seo_title: "TOO_MANY_SIMULTANEOUS_QUERIES Error"
meta:
  description: Learn how to fix the TOO_MANY_SIMULTANEOUS_QUERIES error in ClickHouse and Tinybird. Understand what causes it and see examples of how to resolve it
---

# TOO_MANY_SIMULTANEOUS_QUERIES ClickHouse® error

{% callout %}
This error occurs when the system has reached its limit for concurrent query execution. It's common in high-traffic scenarios or when queries aren't properly managed.
{% /callout %}

The `TOO_MANY_SIMULTANEOUS_QUERIES` error in ClickHouse® (and Tinybird) happens when the system has reached its configured limit for the number of queries that can run simultaneously. This typically occurs in high-traffic scenarios, when applications don't properly manage query connections, or when the system is under heavy load.

## What causes this error

You typically see it when:

- Too many concurrent requests come from your application
- Your application doesn't reuse connections and opens a new one for every request
- Long-running queries block new query execution
- A traffic spike sends more concurrent requests than usual

{% callout type="tip" %}
This error usually points to a need for better concurrency management in your application, not higher limits.
{% /callout %}

## Example errors

```sql {% title="Fails: too many concurrent connections" %}
SELECT * FROM events WHERE timestamp > '2024-01-01'
-- Error: Too many simultaneous queries
```

```sql {% title="Fails: connection limit reached" %}
-- When trying to execute a new query while many are running
INSERT INTO events (user_id, event_type, timestamp) VALUES
(123, 'click', '2024-01-01 10:00:00')
-- Error: Too many simultaneous queries
```

```sql {% title="Fails: high-traffic scenario" %}
-- Multiple applications trying to query simultaneously
SELECT COUNT(*) FROM events WHERE user_id = 123
-- Error: Too many simultaneous queries
```

## How to fix it

### Check current query count

Query `system.processes` to see what's running right now:

```sql {% title="Check active queries" %}
SELECT
    query_id,
    user,
    query,
    elapsed
FROM system.processes
ORDER BY start_time DESC
```

### Check connection usage by user or token

Group by `user` to spot which token or integration is driving concurrency:

```sql {% title="Check connections" %}
SELECT
    user,
    COUNT(*) as active_queries
FROM system.processes
GROUP BY user
ORDER BY active_queries DESC
```

### Review request patterns over time

Query the `tinybird.pipe_stats_rt` Service Data Source to see request volume per API Endpoint and spot the traffic spikes that trigger this error:

```sql {% title="Requests per Endpoint over the last hour" %}
SELECT
    pipe_name,
    COUNT(*) as requests,
    AVG(duration) as avg_duration
FROM tinybird.pipe_stats_rt
WHERE start_datetime >= now() - INTERVAL 1 HOUR
GROUP BY pipe_name
ORDER BY requests DESC
```

### Manage concurrency in your application

Since you call Tinybird over the HTTP API, the fix lives in your application, not in ClickHouse® session settings:

- Reuse HTTP connections with a connection pool instead of opening a new one per request.
- Rate limit how many requests your application sends to Tinybird at once.
- Retry failed requests with exponential backoff instead of firing them again immediately.

```python {% title="Retry with exponential backoff" %}
import time

max_retries = 3
retry_delay = 1  # seconds

for attempt in range(max_retries):
    try:
        result = call_tinybird_endpoint()
        break
    except TooManySimultaneousQueriesError:
        if attempt < max_retries - 1:
            time.sleep(retry_delay)
            retry_delay *= 2
        else:
            raise
```

## Tinybird-specific notes

Tinybird enforces concurrent query limits per Workspace. You only interact with Tinybird through the HTTP API, so you can't raise these limits yourself with ClickHouse® session settings like `max_concurrent_queries`. If your application already manages concurrency well and you're still hitting this error, [contact support](/forward/support) to discuss raising your Workspace's concurrency limits.

{% callout type="tip" %}
Datafiles are declarative: each node's `SQL >` block compiles to a single statement with no session concept. `SET` statements aren't valid in `.pipe` files and fail deployment with `SET is not a valid option in pipe files`.
{% /callout %}

## See also

- [Service Data Sources](/forward/monitoring/service-datasources)
- [Monitoring](/forward/monitoring)
- [Pipes](/forward/core-concepts/pipes)
- [Support](/forward/support)